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Dear  Fellow  ADPA  Member: 

Your  response  to  this  questionnaire  is  requested  to  help  us  identify 
problems  with  Technical  Documentation  in  the  defense  industry.  The 
Technical  Documentation  Division  is  proud  of  the  close  and  effective 
relationship  between  its  industry  and  government  members.  It  is 
through  this  relationship  that  we  can  identify  and  resolve  problems 
for  the  simplification  and  improvement  of  Technical  Documentation. 
Your  participation  is  essential. 

Please  take  a  few  minutes,  complete  the  following  questionnaire,  and 
mail  it  to: 

T.  L.  Golmis 
Hughes  Aircraft  Company 
Bldg.  604,  M/S  F-122 
P.  0.  Box  3310 
Fullerton,  CA  92634 


1.  What  feature  or  talk  given  at  the  1979  meeting  was  the  most 

informative?  _ 

.  .  .  Helpful  to  you?  _ 

2.  What  problems  are  you  having  that  you  would  like  to  see  resolved? 


3.  What  subjects  would  you  like  to  hear  discussed  at  the  1980  meeting 
to  be  held  in  CHARLESTON,  SOUTH  CAROLINA?  _ 

Your  answers  will  be  reviewed  by  the  TDD  Executive  Board.  Where  neces¬ 
sary,  ad  hoc  committees  of  industry  and  government  members  will  be 
created  to  work  your  problems. 

Sincerely , 

T.  L.  Golmis 
Chairman, 

Technical  Documentation  Division 


..'oxments  and  suggestions  are  invited  on  the  reverse  or  attach 
additional  sheets . 
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THE  MISSION 
OF 

THE  AMERICAN  DEFENSE  PREPAREDNESS  ASSOCIATION 


The  American  Defense  Preparedness  Association  exists  solely  for 
the  advancement  of  adequate  national  defense  of  the  United  States 
in  the  fields  of  weapons  technology,  production,  and  logistics. 

We  strive  to  improve  the  effectiveness  and  efficiency  of  the 
Government-Science-Industry  relationship  in  the  development  and 
production  of  weapons  and  weapons  systems.  Our  field  of  interest 
covers  all  ordnance,  armament,  weapons,  weapons  systems,  and 
related  equipment  for  the  Armed  Forces  of  the  United  States.  Our 
interest  also  includes  techniques,  processes,  and  materials  that 
have  wide  application  in  the  development,  production,  and 
logistics  of  weapons. 

Through  its  publications  and  meetings — national,  local,  and 
technical — the  Association  endeavors  to  educate  its  members  and 
the  public  on  problems  affecting  weapons  preparedness.  Our 
technical  divisions  provide  advice  to  Government  agencies  on 
weapons  technology. 

The  Association,  founded  in  1919,  is  a  non-profit  and  non¬ 
political  organization.  It  is  an  association  of  individuals  as 
distinguished  from  an  organization  of  commercial  companies.  The 
ten  persons  nominated  by  company  members  participate  as 
individuals. 

It  is  not  within  the  scope  of  any  American  Defense  Preparedness 
Association  meeting  or  activity  to  discuss  or  be  at  all  concerned 
with  matters  of  trade,  procurement,  price,  market  or  control  or 
with  placement  of  specific  contracts  or  allocation  of  materials. 

The  Association  cooperates  to  every  practical  extent  with  other 
recognized  technical  and  industrial  associations  in  assisting  the 
Armed  Services  of  the  United  States.  Its  mission  is  to  keep 
America's  armament  strong  in  peace  and  in  war.  Its  functions  are 
as  important  and  as  worthy  of  support  in  times  of  international 
quiet,  as  well  as  in  emergency.  It  is  a  peace  society  in  purpose 
in  operations,  and  in  fact. 
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AMERICAN  DEFENSE  PREPAREDNESS  ASSOCIATION 


TECHNICAL  DOCUMENTATION  DIVISION 


STATEMENT  OF  AIMS  AND  PURPOSES 


The  Technical  Documentation  Division  is  part  of  the  Defense  Manage¬ 
ment  Group  of  the  American  Defense  Preparedness  Association.  The 
division  was  formed  to  provide  the  government  and  industry  access 
to  a  group  of  experienced  and  responsible  administrators  and 
specialists  from  various  sectors  of  industry,  qualified  to  assist 
in  the  formulation  of  government  and  industry  requirements  for 
technical  documentation.  The  members  participate  as  individuals 
rather  than  representatives  of  their  companies. 

The  division  is  concerned  with  all  aspects  of  technical  documenta¬ 
tion:  conception,  analysis,  preparation,  management,  control,  and 
dissemination.  The  division's  field  ofinterest  includes  engineer¬ 
ing  drawings  and  standards,  policies  and  procedures,  technical 
publications,  specifications,  configuration  controls,  computer 
aided  documentation  techniques,  and  methods  of  data  communication. 
Duplication  of  effort  by  other  technical  and  industry  associations 
is  avoided. 

Sections/Committees  are  established  to  study  problems  and  submit 
resulting  reports  and  recommendations.  Section/Committee  partici¬ 
pation  by  an  individual  is  voluntary  and  evidences  his  desire  to 
comprehend  government  and  industry  needs,  to  reduce  the  complexity 
and  cost  of  technical  documentation,  and  to  enhance  standardiza¬ 
tion  with  a  sincere  interest  to  serve  with  other  members  to  achieve 
these  goals. 

Division/Section  members  interface  frequently  with  their  counter¬ 
parts  in  government  and  industry.  This  association  serves  as  a 
clearinghouse  for  professional  information  interchange  and  provid¬ 
es  a  stimulation  which  contributes  toward  the  success  of  the 
participant's  work  and  enhances  the  individuals  value  to  his 
employer . 

In  addition  to  section/committee  reports  on  subjects  completed  or 
in  process,  the  Technical  Documentation  Division  convenes  annual¬ 
ly  and  conducts  a  program  of  timely  subjects  to  keep  the  members 
and  the  public  informed,  alert,  and  interested  in  the  problems  and 
solutions  associated  with  technical  documentation  vital  to  our 
national  defense,  industrial  accomplishments,  and  other  related 
prog  rams . 
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Martin  Marietta  Corporation 
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E-Systems  Incorporated 
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Falls  Church,  VA  22046 
(703)  560-5000,  X2555 


EXECUTIVE  BOARD 


MR.  SAMUEL  ALVINE,  JR. 
Kearfott  Division 
The  Singer  Company 
150  Totowa  Road 
Wayne,  NJ  07470 
(201)  256-400,  X 30 3 3 

MR.  JOSEPH  F.  ARMIJO 
Tracor,  Inc,  AARD 
6500  Tracor  Lane 
Austin,  TX  78721 
(after  1  Jul  79) 

MR.  ORMAN  BAKER 
Texas  Instruments,  Inc 
P.O.  Box  6015 
Mail  Station  260 
Dallas,  TX  75222 
(214)  238-2991  or  3930 


MR.  RICHARD  R.  BARTA 
IBM  Corporation,  FSD 
102  8579 

Owego,  NY  13827 
(607)  687-2121,  X2547 

MRS.  LORNA  BURNS 
Hughes  Aircraft  Company 
Bldg  604,  Mail  Station  G244 
P.O.  Box  3310 
Fullerton,  CA  92634 
(714)  732-2013 

MR.  ROBERT  H.  CARRIER 
Raytheon  Company 
Equipment  Development  Lab 
Boston  Post  Road 
Wayland,  MA  01778 
(617)  3  5  8  -  2  7  2 1  ,  X448 


MR.  DONALD  C.  DEROSIA 
General  Electric  Company 
Building  29EE 
1285  Boston  Avenue 
Bridgeport,  CT  06610 


MR.  CHARLES  J.  EMBREY 
Northrup  Services,  Inc 
1700  N.  Lynn  Street 
Arlington,  VA  22209 
(703)  528-5919,  X385 

MR.  CHARLES  D.  FISHER 
RCA 

Government  Communications 
Systems  Division 
Bldg  10-6-2 
Camden,  NJ  08102 
(609)  338-2008 

MR.  ROBERT  F.  FRANCIOSE 
General  Electric  Co,  MC  721 
175  Curtner  Avenue 
San  Jose,  CA  95125 
(408)  925-6880 

MR.  CHARLES  W.  GEDNLY 
RAM  Corporation 
615  South  Frederick  Avenue 
Gaithersburg,  MD  20760 
(301)  840-5960 

MR.  JOHN  R.  HART 
Boeing  Aerospace  Company 
P.O.  Box  3999,  M/S  42-01 
Seattle,  WA  98124 
(206)  655-5159 

MR.  RICHARD  E.  KNOB 
Sperry  Rand  Corporation 
Sperry  Gyroscope  Division 
(516)  574-2436 
♦“♦‘Mailing  Address***** 
3311  Austin  Avenue 
Wantagh,  NY  11793 


MR.  RALPH  LYSYK 
****Home  Address**** 

5824  Kuenzer  Drive 
Seven  Hills,  OH  44131 
(216)  661-3611 

MR.  JOSEPH  R.  MEITZ 
General  Motors  Corporation 
Delco  Electronics  Division 
6767  Hollister  Avenue 
Goleta ,  CA  93017 
(805)  961-5288 

MR.  JOSEPH  J.  O' CALLAHAN 
Avondale  Shipyards  Inc 
Mail  Station  80 
P.O.  Box  50280 
New  Orleans,  LA  70150 
(504)  436-2121,  X596 

MR.  BURTON  G.  SCHAEFER 
Pitney  Bowes 

Copier  Products  Division 
Commerce  Park 
Danbury,  CT  06810 
(203)  792-1600 

MR.  JOHN  R.  SUTTON 
General  Electric 
Ordnance  Systems 
Bldg  8,  Room  8112 
100  Plastics  Avenue 
Pittsfield,  MA  01201 
(413)  494-2208 

DR.  PETER  C.C.  Wang 
Code  53  WG 

Dept  of  Mathmatics  and  National 
Security  Affairs 
Naval  Postgraduate  School 
Monterey,  CA  93940 
(408)  646-2622 
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|  J  n  every  field  of  human  activity  there  are  those  who 
lJ  lead  and  those  who  are  led.  Occasionally,  among  the 
leaders  there  are  individuals  who  achieve  superior  stature. 
In  the  field  of  Engineering  Documentation,  Robert  H. 
Stearns  was  one  who,  through  dedication  to  principle  and 
aggressive  pursuance  of  duty ,  earned  outstanding  recognition 
in  both  industry  and  military  circles. 

Born  in  1SG6  in  New  York  City,  Mr.  Stearns'  career 
included  training  both  as  a  machinist  and  in  engineering  at 
White  Motor  Co.,  and  as  a  drawing  checker ,  chief  cnecker, 
chief  draftsman  and  engineering  consultant  during  twenty- 
five  years  of  service  with  the  Douglas  Aircraft  Company. 

He  was  also  active  personally  arid  as  the  Dongles 
representative  on  vaHous  industry  association  activities, 
special  advisory  committees  to  the  Oeoartment  of  Defense, 
and  with  the  Engineering  Data  Management  Section  of  the 
American  Ordnance  Association.  He  was  taken  from  us  by 
a  most  unfortunate  aircraft  accident  en  route  home  from  a 
meeting  of  the  Steering  Committee  of  the  Engineering  Data 
Management  Section  in  February  1962. 

In  recognition  of  his  outstanding  achievements,  the 
Robert  H.  Stearns  Award  was  established  for  the  purpose  of 
honoring  Mr.  Stearns  and  as  a  vehicle  ta  recognize  and 
honor  those  who  might  exhibit  comparable  dualities  and 
achievement  in  the  future.  Specifically,  candidates  for  the 


Award  are  judged  on  the  basis  of  demonstration  of 
outstanding  qualities  in  the  following  attributes: 

•  Devotion  to  the  field  of  documentation  and 
meaningful  achievement  therein 

•  Vigorous  and  articulate  in  establishing  and 
logically  supporting  a  position 

•  Energetic  with  singleness  of  purpose 

•  Patriotic,  honorable,  pleasant,  humble,  sincere. 

PAST  RECIPIENTS  OF  THE  AWARD 

The  Family  of  R.H.  Stearns . 1953 

VV.  W.  Thomas . 1964 

P.  C.  Weissbrod . 1968 

J.  H.  Mars . 1953 

D.  S.  Scott  . 1969 

P.  G.  Belitsos . 1969 

C.  A.  Nazian . 1970 

J.  L.  Flippo . 1970 

R.  F.  Franciosc . 1971 

G.  D.  Christensen . 1972 

C.  A.  Fricke . 1973 

J,  R.  Meitz  . 1974 

D.  R.  Mitchell . 1977 

H.  R,  Lowers . 1978 


,\jr.  Maurice  E.  Taylor  has  been  actively  engaged  in  the  field  of  engineering  documentation 
IjVjfor  over  30  years.  He  is  a  graduate  of  Lehigh  University  and  has  35  years  of  government 
service.  Our  history  record  shows  Mr.  Taylor  as  a  specification  writer  for  Fire  Control  in  the  late 
1940's  and  early  1950's.  In  the  early  1 950's,  when  the  Department  of  Defense  initiated  the 
standardization  program,  Mr.  Taylor  became  Chief  of  the  Specifications/Standards  Section  at  the 
Frankford  Arsenal. 


Mr.  Taylor  is  presently  Chief  ARRADCOM-Specifications  and  Standards  Section  located  at  Picatinny  Arsenal,  Dover, 
New  Jersey.  He  is  also  the  Manager  of  the  DOD  DRPR  Program;  Chairman  of  the  DOD  Select  Committee  on  DOD-D-IOOO, 
which  includes  DOD-STD  100;  principal  member  of  the  U.S.  Army  Quadripartite  Working  Group  on  Engineering  Standardi¬ 
zation  Program;  ABCA-UES  Army  Liaison;  ARRADCOM  member  of  the  Engineering  Design  Advisory  Group;  a  member  of 
a  number  of  ANSI  committees;  and,  last  but  not  least,  the  Army  Liaison  member  of  our  ADPA  Technical  Documentation 
Executive  Board. 

Because  of  his  knowledge  and  background,  Mr.  Taylor  is  a  focal  point  for  both  industry  and  military  personnel's  questions 
and  requests  for  consultation.  His  combined  leadership  and  fundamental  good  background  have  brought  him  increasing 
respect  as  he,  in  his  quiet  and  effective  manner,  works  through  one  task  after  another  in  the  development  of  the  various 
aspects  of  standardization. 

Through  his  leadership,  continued  revisions  to  the  drawing  standards  are  bringing  industry  and  military  closer  to  a  single 
national  standard.  Mr.  Taylor  is  truly  dedicated  to  the  promotion  and  use  of  specifications  and  standards.  He  has  always 
been  responsive  to  the  needs  of  industry  as  well  as  the  Department  of  Defense.  One  of  his  present  concerns  is  the  impact  of 
international  standardization  on  national  industry/military  standards. 


Mr.  Taylor  has  been  associated  with  the  ADPA  Technical  Documentation  Group  for  many  years,  and  his  contributions 
are  innumerable.  He  is  a  frequent  speaker  at  our  annual  meetings  and  regularly  attends  our  Steering  Committee  meetings, 
keeping  us  informed  of  the  latest  developments. 

We  value  his  support  of  our  endeavors  and  look  forward  to  the  guidance  and  professionalism  he  adds  to  our  group. 

He  and  his  wife  Lois  live  in  Riverton,  New  Jersey,  and  were  blessed  with  four  children.  He  has  two  married  daughters 
and  e  son  and  a  daughter  in  college.  He  is  a  grandfather  of  two  boys  and  two  girls. 

Mr.  Taylor  is  an  ardent  fishing  and  boating  enthusiast  and  enjoys  traveling. 

A  person  who  possesses  the  unique  qualities  and  high  standards  to  merit  this  award  -  dedication  to  the  field  of  standardi¬ 
zation,  articulation,  responsiveness,  humility,  sincerity  -  is  Maurice  E.  Taylor. 
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Pitney  Bowes 

Copier  Products  Division 


WELCOMING  ADDRESS 


REAR  ADMIRAL  TYLER  F.  DEDMAN 
Superintendent 
Naval  Postgraduate  School 


Admiral  Dedman  graciously  welcomed  the  Technical 
Documentation  Division  of  the  American  Defense  Pre¬ 
paredness  Association  to  the  Naval  Postgraduate 
School.  He  discribed  the  current  role  of  the  school 
in  our  national  defense  and  provided  a  brief  summary 
of  history  of  the  Naval  Postgraduate  School.  He  ex¬ 
pressed  his  appreciation  to  the  division  for  opening 
the  meeting  to  students  of  the  school. 


American  Defense  Preparedness  Association 
TECHNICAL  DOCUMENTATION  DIVISION 
1979  ANNUAL  REPORT 
by 

THEODORE  L.  GOLMIS 

Manager,  Configuration  and  Data  Management  Operations 
Hughes  Aircraft  Company 

and 

Chairman,  Technical  Documentation  Division 


Good  morning,  ladies  and  gentlemen.  I  would  like  to  take  this 
opportunity  to  express  my  personal  appreciation  and  that  of  the 
American  Defense  Preparedness  Association  to  all  of  the  indivi¬ 
duals  that  have  made  this  meeting  possible. 

In  particular,  I  would  like  to  thank  Rear  Admiral  Dedman  for  his 
kindness  in  hosting  our  twenty-first  annual  meeting  of  the  Techni¬ 
cal  Documentation  Division  here  at  the  Naval  Postgraduate  School. 
We  are  indeed  privileged  to  be  able  to  share  the  facilities  of  one 
of  the  finest  graduate  institutions  in  the  Country  in  a  setting  as 
lovely  as  the  Monterey  Peninsula. 

It  also  gives  me  great  pleasure  to  thank  Mr.  Robert  H.  Carrier, 
Raytheon  Company,  our  Program  Chairman  and  Dr.  Peter  C.  C.  Wang, 
Naval  Postgraduate  School,  our  Business  Manager  who  have  worked 
for  months  formulating,  arranging,  and  managing  this  twenty-first 
annual  meeting.  Thank  you  gentlemen. 

It  has  been  our  custom  each  year  to  open  our  meeting  with  an 
annual  report.  Last  year  in  New  Orleans,  because  that  meeting  re¬ 
presented  our  Twentieth  Anniversary,  I  attempted  to  recap  our 
first  year  and  highlight  the  other  nineteen  years.  At  that  meet¬ 
ing,  I  stated  that  two  decades  ago  under  the  banner  of  Engineering 
Documentation  Section  of  the  American  Ordnance  Association,  this 
group  became  actively  involved  in  matters  associated  with  Defense 
and  Space  Documentation.  A  small  dedicated  group  interested  in 
problem  solving,  initiated  a  movement  that  has  lasted  twenty 
years.  I  said,  "twenty  years  ago  men  with  insight  set  as  their 
objectives  for  this  section  the  establishment  of  a  two-way  channel 
of  communication  between  military  and  industry.  They  hoped  to  pro 
vide  a  sounding  board  by  which  the  military  could  obtain  the  bene¬ 
fits  of  a  cross-section  of  industry  experience  through  the  coordi¬ 
nation  of  information  regarding  new  requirements  and  problems." 


Since  twenty  years  is  too  much  to  cover  in  the  alloted  time,  I 
would  like  to  highlight,  in  slightly  more  detail,  our  last  five 
years — looking  at  objectives  and  accomplishments. 


Five  years  ago  at  Stouffer's  Riverfront  Inn  in  St.  Louis, 

Missouri,  Mr.  Joseph  R.  Meitz,  Delco  Electronics,  our  Section 
Chairman  at  that  time,  set  forth  the  objectives  for  the  year  to 
come.  They  included: 

(1)  Increase  our  Steering  Committee  from  the  existing 
seventeen  members  to  twenty. 

(2)  Broaden  our  interest  base  and  establish  appropriate 
committees  for  such  activities. 

(3)  Continue  our  push  with  ADPA  Headquarters  to  establish  a 
working  relationship  with  the  American  National  Stan¬ 
dards  Institute  (ANSI). 

(4)  Establish  closer  working  relationships  with  other  groups 
and  industry  associations. 

(5)  Continue  our  efforts  for  closer  and  better  working 
relationships  with  the  Department  of  Defense  (DoD)  and 
the  individual  branch  Services. 

Those  objectives  basically  set  the  goals  for  that  coming  year  and 
the  years  that  followed.  Here  is  how  they  have  been  satisfied: 

(1)  Increase  the  Steering  Committee  from  the  existing 
seventeen  to  twenty. _ 


This  was  accomplished  in  that  first  year  and  we  have 
retained  a  membership  of  twenty  or  more  since  that  time. 
The  current  Steering  Committee,  now  known  as  the  Execu¬ 
tive  Board,  consists  of: 

Officers: 

Chairman  Theodore  L.  Golmis,  Hughes  Aircraft  Co 
Secretary  Robert  A.  Timlin,  Martin  Marietta  Corp 
Membership  Joseph  V.  Symanoskie,  Melpar  Division, 
E-Systems,  Inc 


Members: 


Samuel  Alvine,  Jr 
Joseph  F.  Armijo 
Orman  Baker 
Richard  R.  Barta 
Lorna  Burns 
Robert  H.  Carrier 
Donald  C.  Derosia 
Charles  D.  Fisher 


Kearfott  Division,  Singer  Company 

Tracor  Incorporated 

Texas  Instruments 

IBM  Corporation 

Hughes  Aircraft  Company 

Riaytheon  Company 

General  Electric  Company 

RCA  Corporation 


Members  (continued) 


Robert  F.  Franciose  General  Electric  Company 

Charles  W.  Gedney  Research  Analysis  and  Management  Corp 

John  R.  Hart  Boeing  Aerospace  Company 

Richard  E.  Knob  Sperry  Rand  Corporation 

Ralph  Lysyk  Addressogr aph  Multigraph  Corporation 

Joseph  R.  Meitz  General  Motors,  Delco  Electronics 

Joseph  O'Callahan  Avondale  Shipyards  Incorporated 

Ourton  G.  Schaefer  Pitney  Bowes 

John  R.  Sutton  General  Electric,  Ordnance  Systems 

Or.  Peter  C.C.  Wang  Naval  Postgraduate  School 

Government  Liason  Representatives: 

Richard  L.  Berry  Naval  Material  Command 
John  J.  Durante  U.S.  Marine  Corp 

James  D.  Federline  Defense  Loqistics  Agency 
Lt  Col 

William  Fohrman  U.S.  Air  Force,  WPAFE 
Maurice  E.  Taylor  U.S.  Army,  ARADCOM 


The  Steering  Committee  was  restructured  as  an  Executive 
Board  at  the  Division  level  in  1977  and  now  includes  the 
various  Section  Chairmen  (formerly  Committee  Chairmen). 

January  1978  marked  the  first  of  the  newly  formatted 
Executive  Board  Meetings.  The  meeting  was  held  "on- 
post"  at  Redstone  Arsenal,  Huntsville,  Alabama.  Our 
host  was  the  ADPA  Tennessee  Valley  Chapter.  Colonel 
Michael  Dooley,  Army  Missile  Materiel  Readiness  Command 
and  President  of  the  Tennessee  Valley  Chapter;  Mr. 

Horace  Lowers;  and  Mr.  Leland  Womack  assisted  in  those 
arrangements.  The  meeting  was  attended  primarily  by 
civilian  elements  of  Redstone  Arsenal.  The  Military 
Liason  Representatives  and  Section  Chairmen  reports  were 
well  received  and  provided  an  excellant  exchange  with 
attendees. 


Our  second  such  meeting  was  held  at  Eglin  Air  Force 
Base,  Fort  Walton  Beach,  Florida.  The  meeting  was 
arranged  through  Colonel  Clifford  Allen,  Chief  of  Guided 
Weapons  and  President  of  the  ADPA  Gulf  Coast  Chapter. 
This  meeting  aided  in  determining  the  current  interests 
and  suggested  topics  that  we  should  address  at  this 
annual  meeting. 


Our  objective  is  to  enhance  our  annual  meetings  by  tak¬ 
ing  advantage  of  those  "participant  with  a  message" 
that  we  encounter  through  these  Executive  Board  meet¬ 
ings.  We  will  accumulate  new  topics,  timely  subject 
matter,  and  unresolved  pr oblems- -hope fu 1 ly-- for  reso¬ 
lution  at  our  Annual  Meetings.  Both  the  Annual  Meeting 


and  Executive  Board  Meetings  will  be  rotated  around  the 
United  States  to  maximize  our  exposure  to  the  "real 
world"  and  expand  the  exchange  of  current  information 
between  government  and  industry. 

(2)  Broaden  our  interest  base  and  establish  appropriate 
committees  (sections)  for  such  activities. 


The  existing  committees,  sections,  and  their  chairmen 
are  as  follows: 

Sections 

Armed  Services  Procurment  Regulations 
Computer  Software 
Configuration  Management 
Contract  Data  Management 
Engineering  Data  Automation 
Engineering  Drawing  Requirements 
International  Data  Requirements 
Metrication 

Micro-Reproduction  Systems 
Preparation  and  Management  of 
Specifications 
Technical  Publications 

Committees 

Awards  Committee  J.R.  Meitz 

The  establishment  of  these  sections  seems  now  to 
adequately  cover  the  field  of  technical  documentation 
and  permits  our  involvement  in  many  interrelated 
activities  and  interest  areas. 

Let  me  highlight  some  of  our  sections'  activities  and 
interests: 

ASPR  Section  -  Charles  D.  Fisher 

This  section  is  standing  by  for  action.  The  past  years 
have  contributed  to  some  very  interesting  activity,  but 
now  under  the  new  "Acquisition  Regulation  Committee"  and 
with  the  transition  from  ASPRs  to  Federal  Acquisition 
Regulations  (FARs)  we  should  see  significant  changes  in 
the  areas  of  deferred  ordering,  government  wide  procure¬ 
ment  of  automated  data  processing  (ADP)  capabilities  and 
rights  in  software  data,  data  required  by  ASPR  not 
listed  in  the  Contract  Data  Requirements  List  (CDRL), 
data  pricing,  engineering  change  proposals  (ECPs),  and 
contract  clauses.  1979-1980  should  be  a  most 
interesting  year. 


C.D.  Fisher 
Orman  Baker 
C.J.  Embrey 
J.R.  Hart 
Dr.  P.  Wang 
J.R.  Meitz 
T.L.  Golmis 
Lorna  Burns 
J.R.  Sutton 

S.  Alvine,  Jr 
R.E.  Knob 


The  scope  of  this  section  is  limited  to  the  documenta¬ 
tion  in  an  engineering  drawing  system  of  computer 
programs  that  are  delivered  to  a  customer.  It  is  not 
the  intent  to  cover  all  aspects  of  computer  programs, 
per  se.  A  description  of  Computer  Software  Drawings  has 
been  submitted  for  inclusion  in  ANSI  Y14.24,  "Types  and 
Application  of  Engineering  Drawings"  (proposed).  This 
document  is  expected  to  replace  Chapter  200  of 
DOD-STD-IOOC  (formerly  MIL-STD-100 ) . 


Comments  have  been  received  on  the  Navy  coordinated 
specification  for  Software  Management,  MIL-STD-1679 ,  and 
are  currently  being  consolidated  for  submittal  to  the 
Navy.  A  list  of  definitions  dealing  with  computer 
program  terminology  is  currently  being  compiled. 


Configuration  Management  Section  -  Charles  J.  Embrej 


Mr.  Embrey  has  just  recently  taken  over  this  section. 
We  were  terribly  saddened  shortly  after  last  year's 
annual  meeting  when  our  Program  Chairman  for  that  year 
and  CM  Section  Chairman,  Lyle  Alexander,  passed  away. 


There  is  significant  activity  on  the  horizon  for  this 
section  and  we  expect  to  see  a  number  of  improvements  in 
the  documents  originating  from  the  Joint  DoD  Configura¬ 
tion  Management  Committee  under  the  chairmanship  of 
Richard  L.  Berry,  Naval  Material  Command. 


Activity  in  the  recent  past  includes  involvement  in  the 
industry  review  of  the  DoD  CM  Standardization  Plan;  DoD 
Directive  4120.3,  Defense  Standardization  and  Specifi¬ 
cation  Program;  MIL-STD-480A,  Configuration  Control, 
Engineering  Changes,  Deviations,  and  Waivers;  and  parti¬ 
cipation  in  the  Arlie  House  workshop  on  MIL-STD-480 
Tailoring  Guide,  MI L-HDBK-2 48 ,  Tailoring  Guide  for  Appli¬ 
cation  of  Specifications  and  Standards,  MIL-HDBK-245 , 
Preparation  of  Statement  of  Work,  MIL-STD-35,  Automated 
Engineering  Document  Preparation,  MIL-STD-XXX,  and 
Configuration  Management  Practices. 


Contract  Data  Management  Section  -  John  R.  Hart 


This  section  has  commented  on  a  preliminary  draft  of  DOD 
Directive  5100.36,  "Development  and  Acquisition  Informa¬ 
tion".  (This  directive  is  the  parent  document  for  DoD 
Directive  5010.12,  "Management  of  Technical  Data".)  DoD 
Directive  5000. 32M  (draft),  "Acquisition  Management  Sys¬ 
tems  and  Data  Requirements  Control  Program  Manual"  was 
sent  to  fifty-two  section  and  division  members  for 
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review  and  comment.  Serveral  items  resulting  from  last 
year's  workshop  on  data  have  developed  into  assignments. 
They  include: 


Development  of  consensus  DIDs  -  Chairman  M. 
Michaelis,  U.S.  Navy 

Reduction  in  use  of  DD  Form  250  for  the  delivery  of 
data  -  R.  Hall,  Motorola. 

Upstream  mutual  RFP  involvement  -  J.  Parish,  U.S. 

Air  Force. 

During  the  next  quarter,  the  Contract  Data  Management 
Section  plans  to: 

-Follow-up  on  DoD  Directive  5000. 32M  draft. 

-Complete  1979  workshop  action  items. 

-Continue  on-going  review  of  government  media. 

Engineering  Data  Automation  Section  -  Dr.  Peter  C.C.  Wang 


In  November  1979,  this  section  will  sponsor  the  Second 
Symposium  on  Automated  Technology  in  Engineering  Draw¬ 
ings  here  at  the  Naval  Postgraduate  School.  There  will 
be  special  sessions  on  automated  production  of  digitized 
engineering  data,  storage,  retrieval,  display  and  trans¬ 
mission  of  digital  data,  and  the  future  of  automation 
technology  in  engineering  data.  (I  understand  that  we 
have  approximately  three  hundred  who  have  indicated  a 
desire  to  attend.) 

Engineering  Drawing  Requirements  Section  -  Joseph  R. 


Meitz 

This  section  now  consists  of  forty  active  members.  The 
section's  prime  effort  this  past  year  was  confined  to  a 
final  review  of  the  Guide  for  Application  and  Tailoring 
of  DOD-D-1000  which  is  now  Amendment  1  to  that  document 

Tasks  planned  for  1979  include: 

-Envolvement  with  numbering,  nomenclature,  and 
drawing  package  callout  of  software. 

-Review  of  the  proposed  revision  to  the  Air  Force 
document  AFAD-71-700. 

-Review  of  ANSI  documents  planned  to  replace 
military  specification  and  standards  related  to 
drawings,  as  proposed. t 

-The  priority  task  for  this  section  will  be  to 
review  and  propose  clarifications  of  the 


definition  and  requirements  for  procurement  docu¬ 
mentation  including  specification  and  source  control 
drawings.  This  task  is  the  result  of  a  request  from 
the  Defense  Material  Specification  and  Standards 
Office  (DMSSO) . 

International  Data  Requirements  Section  -  T.L.  Golmis 
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onal  data  requirements  are  getting  a  great  deal 
ion  as  the  result  of  the  recent  DoD/NATO  agree- 
the  areas  of  Reciprocal  Defense  Procurement, 
s  Governing  Mutual  Cooperation  in  Research, 
nt.  Production,  and  Procurement  of  Defense 
,  and  NATO  Rationalization,  Standardization, 
operability  (RSI)  Working  Group.  Section  acti- 
ild  be  increasing  in  the  coming  year. 


Metrication  Section  -  Lorna  Burns 

The  Metrication  Section  consists  of  twenty-five  industry 
members  and  eight  government  liason  representatives. 

This  section  is  responsible  for  reviewing  government 
directives,  standards,  and  specifications  involving 
metrics;  respoinding  to  ANSI's  requests  for  public  re¬ 
view  of  proposed  national  metric  standards;  providing 
metrication  guidance  and  assistance  to  various  branches 
of  the  government  upon  request;  and  keeping  members 
informed  of  current  trends  and  activities  relative  to 
metrication.  These  activities  have  included  review  of: 


DOD-STD-1476 


DOD-M-24680 


ANSI  B4. 2-1978 


ANSI  B4. 3-1978 


Metric  System,  Application  in 
New  Design 

Metric  Machinery/Equipment, 
General  Requirements  for 

Preferred  Metric  Limits  and  Fits 

General  Tolerances  for  Metric 
Dimensioned  Products 


A  proposed  revision  of  the  national  standard  for  metric 
practices,  IEEE  STD  268-1979,  has  just  been  sent  to 
section  members  for  review. 


Micro-Reproduction  Section  -  John  R.  Sutton 
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Preparation  and  Management  of  Specification  Section  - 
Samuel  Alvine,  Jr 

Mr.  Alvine's  big  task  this  year  was  the  coordination  of 
the  combined  standard  DOD-STD-4 90/961^  I  won't  expand 
upon  this  review,  since  you  will  be  discussing  the  subject 
later . 

Technical  Publications  Section  -  Richard  E.  Knob 

In  addition  to  arranging  for  ADPA  sponsorship  of  the 
Integrated  Technical  Documentation  and  Training  ( I TDT ) 
Workshops  for  industry,  this  section  is  interested  in 
reducing  the  number  of  specifications  required  for 
technical  manuals. 

I  think  this  brief  summary  of  activities  pretty  well 
indicates  our  broadened  interest  base. 


(3)  Continue  our  push  with  ADPA  to  establish  a  working 
relationship  with  ANSI. 


We  have  been  very  fortunate  over  the  years  to  have  on 
our  Executive  Board  Bob  Franciose,  Chairman  of  the  Y14 
Executive  Committee  which  is  responsible  for  a  majority 
of  the  ANSI  documents  which  we  use.  Through  him,  and 
people  like  Charles  A.  Fricke,  Chairman  of  the  Y32  Com¬ 
mittee,  and  Lorna  Burns  and  Joseph  R.  Meitz,  both  Chair¬ 
men  of  Y14  Subcommittees,  we  have  been  able  to  remain 
informed  and  to  participate  in  the  development  and 
revision  of  ANSI  standards. 

(4)  Continue  to  establish  closer  working  relationships  with 
other  groups  and  industry  associations. 


We  have  over  the  last  several  years  developed  an  excel¬ 
lent  working  relationship  with  AIA,  EIA ,  and  NSIA.  They 
joined  us  on  the  five  city,  nationwide  Seminar  on 
MIL-D-1000/MI L-STD-10 0 ,  on  the  East  Coast/West  Coast 
Seminar  on  Tailoring  of  Specifications  and  Standards, 
and  the  Arlie  House  Workshop.  This  cooperative  effort 
has  afforded  us  many  opportunities  to  eliminate  duplica¬ 
tion  of  effort  and  maximize  our  industry  positions 
through  unification. 

(5)  Continue  our  effort  for  closer  and  better  working  rela- 
tionship  with  the  DoD  and  individual  branch  Services. 


The  fullfilment  of  this  objective  has  been  very  reward¬ 
ing.  Five  years  have  seen  significant  improvement  in 
our  relationship  with  DoD  and  the  Services  and  have  re¬ 
sulted  in  benefits  to  both  Government  and  industry. 
DoD's  support  of  the  MIL-D-1000/MIL-STD-100  Seminars, 


and  the  Tailoring  Seminars  and  Workshop,  made  them 
worthwhile  ventures.  A  good  working  rapport  made  possi¬ 
ble  the  inclusion  of  the  substitution  statement  in 
MIL-STD-480,  defeated  the  32-digit  number  proposal,  and 
permitted  the  establishment  of  an  investigative  task 
team  under  DARCOM  for  the  review  of  duplicate  drawing 
problems. 

The  closer  and  better  working  relationship  with  DoD  and 
the  individual  branches  Services  must  always  be  our 
Number  One  objective. 


Those  were  the  objectives  in  1974  as  established  by  Mr.  Meitz.  In 
addition  to  fulfilling  those  objectives,  we  have  seen  many  other 
accomplishments  including  a  continual  improvement  in  our  annual 
meeting.  Our  speakers  have  been  outstanding,  our  workshops  ever 
growing,  and  attendance  increasing.  (By  the  way  we  have  tentative¬ 
ly  selected  Charleston,  South  Carolina  as  the  site  of  our  next 
annual  meeting.) 

I  am  extremely  proud  of  the  men  and  women  who  have  contributed  so 
much  to  the  success  of  this  organization  and  thank  you  who  attend 
our  meetings  and  exchange  with  us  your  knowledge  and  expertise  so 
that  we  may  better  serve  government  and  industry. 


Thank  you. 


SOFTWARE  CONFIGURATION  MANAGEMENT 


John  A.  Campbell 
Software  Staff  Engineer 

Martin  Marietta  Aerospace 
Denver,  Colorado 


A  presentation  of  a  practical  approach  to  software  configuration 
management  based  upon  actual  methods  and  procedures  that  were 
successful  in  achieving  configuration  management  of  flight 
operations  software  on  the  Viki.ng  project. 


SOFTWARE  CONFIGURATION  MANAGEMENT 


INTRODUCTION 

Applying  the  configuration  management  disciplines  to  hardware  end  products 
has  been  successfully  accomplished  for  many  years.  However,  when  these 
same  disciplines  are  applied  to  the  software  end  product,  there  appears 
to  be  difficulty  in  understanding  when  and  how  to  apply  them. 

An  in-depth  discussion  of  all  of  the  potential  procedures  that  could  be 
implemented  to  achieve  software  configuration  management  is  not  possible 
in  the  time  allotted  for  this  presentation.  Therefore,  this  presentation 
will  highlight  the  procedures  that  were  successful  on  the  Viking  project 
for  software  configuration  management. 

VIKING  SOFTWARE  CONFIGURATION  MANAGEMENT 

The  major  factor  in  achieving  successful  software  configuration  management 
on  the  Viking  project  was  the  implementation  and  strict  enforcement  of 
disciplines  on  the  software  development  personnel . 

Detailed  schedules  were  established  for  all  phases  of  software  development 
as  well  as  for  the  preparation  of  specifications,  test  plans,  and  support 
documentation.  Schedule  status  was  reviewed  at  regular  weekly  reviews 
and  all  software  problems  were  highlighted  and  resolved  on  a  scheduled 
basis. 

The  total  responsibility  for  the  development  of  the  Viking  Lander  software 
was  delegated  to  a  Viking  Lander  Software  Systems  Engineer  (VLSSE).  This 
software  systems  engineer  played  a  dual  role  in  that  he  suoervised  the 
configuration  management  of  the  Viking  Lander  software  in  Denver,  Colorado, 
and  later  supervised  the  configuration  management  of  all  Viking  project 
software  at  the  Jet  Propulsion .Laboratory  in  Pasadena,  California.  This 
SSE  and  his  staff  were  primarily  responsible  for  implementing  the  config¬ 
uration  management  disciplines  on  all  Viking  software  and  rigorously  enforcing 
these  procedures. 

The  Viking  Lander  software  which  was  designed  and  developed  by  Martin 
Marietta  in  Denver  was  initially  tested  in  Denver  to  demonstrate  that  it 
satisfied  the  software  requirements.  This  Denver  test  was  designated  as 
a  certification  test. 

After  the  successful  completion  of  the  certification  test,  the  Lander  soft¬ 
ware  programs  were  taken  to  the  Jet  Propulsion  Laboratory  (JPL)  in  Padadena, 
California  where  they  were  put  through  a  user's  acceptance  test. 


After  the  successful  completion  of  the  user's  acceotance  test,  the  Lander 
software  programs  were  submitted  to  the  Data  Systems  Integration  Group  at 
JPL  where  they  were  put  through  integration  testing.  During  integration 
testing,  the  Viking  Lander  and  Drbiter  software  was  integrated  into  the 
Mission  Operations  Software  System  (MOSS). 

During  all  of  these  scheduled  tests,  certification  user  acceptance  and  mission 
integration,  the  software  programs  had  the  configuration  management  disciplines 
imposed  upon  them. 

CONFIGURATION  MANAGEMENT 

Configuration  management  is  a  discipline  of  aoplyina  technical  and  adminis¬ 
trative  direction  and  surveillance  to  three  elements.  These  elements  are: 
Configuration  Identification,  Configuration  Control,  and  Conf iouration 
Status  Accounting. 

On  the  Vikino  project,  the  elements  of  configuration  management  were 
applied  as  follows: 

A.  Configuration  Identification 


Configuration  identification  is  the  establishment  of  a  baseline  from 
which  configuration  (change)  control  can  be  imposed. 

For  software,  configuration  identification  reouired  the  establishment 
of  a  baseline  on: 

1.  The  Computer  Program  Development  (CpCI-Part  1-95)  Soecif ication. 

2.  The  Computer  Program  Product  (CPCI-Part  II-C5)  Specification. 

Note:  The  formal  release  of  these  specifications  after  aoproval 

baselines  these  documents  and  places  them  under  formal  chance 
control . 

3.  The  CPCI  that  consists  of  a  tape  or  disk  nack  and  nronram  listina. 
Baselinina  of  the  CPCI  is  accomplished  orior  to  the  start  of  formal 
testina  by: 

a.  The  successful  completion  of  checkout  and  debugoino  of  the 
CPCI  by  the  cognizant  ornorammer. 


b.  Identifyino  the  CPCI  with  a  uninue  version  identification  number 
both  internally  and  externally. 


c.  Preparation  of  an  inventory  list  (or  eoui valent)  that  specifies 
the  version  of  the  CPCI  and  all  related  software  documents.  This 
inventory  list  is  the  packing  slip  for  the  software  inventory  pack¬ 
age  being  basel ined. 

d.  By  placing  the  software  inventory  package  in  the  Program  Support 
Library  to  prevent  unauthorized  access  or  changes  to  the  base¬ 
lined  CPCI  after  acceDtance  by  a  test  readiness  review. 

Configuration  Control 

Configuration  control  is  the  evaluation,  coordination,  and  approval  (or 

disapproval)  of  changes  to  an  established  baseline. 

For  the  software  end  oroduct,  this  is  achieved  by  the  following: 

1.  All  proposed  software  changes  were  formally  approved  by  the 
cognizant  program  change  authority  prior  to  their  incorporation. 

2.  The  baselined  CPCI  and  the  program  listing  were  requested  from  the 
program  support  library  by  the  software  programmer  making  the 
approved  change. 

3.  The  program  support  library  placed  the  data  from  the  baselined  soft 
ware  program  into  the  computer  and  provided  the  program  listing  to 
the  programmer.  This  created  a  working  copy  of  the  baselined  tape 
(or  disk  pack)  to  be  used  bv  the  programmer  for  changes.  The 
original  baselined  tape  (or  equiv.)  remains  active  in  the  program 
support  library  until  superceded  by  a  new  baselined  version  of 

the  software  end  product. 


4.  The  programmer  makes  the  changes  to  the  program  and  after  testing 
and  acceptance  of  the  changed  program  by  software  quality  assurance 
the  changed  version  of  the  program  is  put  on  tape  (or  equivalent), 
reidentified  with  a  new  version  number,  and  placed  in  the  program 
support  library.  The  previous  version  of  the  program  is  placed 

in  a  history  file  in  the  program  support  library. 

5.  Baselined  documents  that  are  affected  by  changes  made  during  formal 
testing  may  be  red-lined  during  the  actual  test,  however,  these 
documents  must  be  formally  updated  at  the  completion  of  the  test 
and  prior  to  the  acceptance  of  the  software  test  report. 

Configuration  Status  Accounting 

Configuration  status  accounting  is  the  recording  and  reporting  of  the 

information  that  is  needed  to  manage  configuration  effectively.  This 


shall  include  a  listing  of  the  approved  configuration  identfication, 

and  the  implementation  status  of  approved  changes. 

The  following  items  are  required  for  software  configuration  status 

accounting: 

1.  Configuration  Identifiers  -  Each  computer  tape  or  disk  shall  be 
uniquely  marked  with  an  identifier  both  internally  and  externally. 

?..  Each  patch  deck  shall  be  uniquely  identified  and  traceable  to  its 
related  listing. 

3.  A  listing  produced  from  a  tape  or  disk  shall  be  uniquely  identified 
and  traceable  by  its  identifier  to  the  deck  or  disk  and  version 
from  which  it  was  produced. 

4.  Any  change  to  the  contents  of  a  tape  or  disk  is  a  change  in  its 
configuration  and  shall  be  reflected  in  a  corresponding  change  to 
its  configuration  (version)  identifier. 

5.  Traceability  of  software  changes  shall  be  achieved  as  follows: 

a)  Any  change  to  a  tape  or  disk  shall  be  traceable  to  specific 
instructions  and/or  data  that  were  changed  (added,  deleted 
or  modified)  by  identification  of  the  affected  items  on  its 
related  program  listing. 

b)  Each  patch  to  memory  shall  be  traceable  to  the  memory  location 
it  changes,  and  to  the  previous  and  new  contents. 

c)  Each  patch  deck  shall  be  traceable  to  the  tape  or  disk  pack 
(and  tape  or  disk  pack  versions)  it  Datches  and  to  the  problem 
it  corrects. 

d)  Changes  to  the  source  program  shall  be  identifiable  in  terms  of 
source  instructions  removed  and  added,  their  positions  (sequence 
numbers)  in  the  source  program  and  on  its  related  program  listing. 

6.  The  preparation  and  approval  of  a  version  identification  listing 
(or  equivalent)  by  the  PSL  constitutes  acceptance  of  the  CPCI  by 
listing  all  approved  changes,  and  the  authorized  sign-off  signa¬ 
tures  for  change  acceDtance. 

THE  COMPUTER  PROGRAM  CONFIGURATION  ITEM 

The  Computer  Program  Configuration  Item  (CPCI)  consists  of  a  tape  or  disk 
pack  and  a  program  listing. 


The  tape  or  disk  pack  is  the  repository  for  all  of  the  computer  program 
data  and  provides  the  means  by  which  the  computer  program  is  placed  into 
a  computer  to  perform  its  intended  function. 

The  program  listing  is  generated  when  the  computer  program  is  placed  in 
the  computer  and  provides  a  complete  detailed  list  of  the  computer  program 
that  is  on  the  tape  or  disk  pack. 

The  CPCI  is  a  part  of  an  inventory  of  software  items  which  are  baselined 
to  implement  configuration  management.  This  inventory  includes  the  computer 
program  development  specification  (CPCI  Part  I-B5),  the  computer  program 
product  specification  (CPCI  Part  II-C5),  the  user  guide,  and  all  other 
documentation  related  to  this  CPCI  version. 

On  the  Viking  project,  the  software  inventory  package  which  contained  the 
CPCI  version,  was  assembled  and  submitted  at  test  readiness  reviews  for  each 
major  test  milestone;  certification  tests,  user's  acceptance  tests,  and 
mission  integration  tests.  When  the  test  readiness  review  board  accepted 
the  submitted  software  inventory  package,  it  was  placed  in  the  Program 
Support  Library  (PSL)  under  the  control  of  the  software  quality  function. 

After  the  successful  completion  of  each  scheduled  test,  the  revised  CPCI 
w§s  accepted  along  with  a  record  list  of  all  changes  to  the  CPCI  and  all 
related  documentation.  This  new  version  identification  list  was  signed  off 
by  the  software  quality  function  to  provide  a  status  accounting  record. 

PROGRAM  SUPPORT  LIBRARY 

To  provide  configuration  management  that  will  be  acceptable  to  the  customer, 
it  is  mandatory  that  the  configuration  management  of  software  be  under 
cognizance  of  a  quality  assurance  function.  A  Program  Support  Library  (PSL) 
under  the  supervision  and  control  of  the  quality  assurance  function  is  the 
means  by  which  this  is  accomplished.  The  Program  Support  Library  provides 
support  for  software  configuration  management  by  rigidly  enforcing  the  pro¬ 
cedures  that  provide  for  the  identification,  control,  and  status  accounting 
of  the  CPCI  and  its  related  documentation. 

On  the  Viking  project,  the  program  support  library  at  the  Jet  Prooulsion 
Laboratory  was  part  of  the  Data  System  Integration  group  which  provided  the 
implementation  and  enforcement  of  all  configuration  management  procedures 
under  the  supervision  of  the  Vikina  project  software  system  engineer  and 
his  staff. 

SUMMARY 

The  successful  achievement  of  software  configuration  management,  on  the 
'/iking  project,  was  dependent  upon  the  rigorous  apnlication  of  disciplines. 


Software  development  and  documentation  schedules  were  established  to 
provide  the  visibility  of  schedule  performance  for  software  development 
which  was  normally  apparent  for  hardware  development. 

The  Viking  project  software  system  engineer  and  his  staff  established, 
implemented  and  effectively  enforced  all  of  the  procedures  for  the  follow¬ 
ing  configuration  management  elements: 

Conf iguration  Identification  established  by: 

1.  The  unique  identification  of  the  CPCI  version  to  provide  a  baseline  from 
which  change  can  be  imposed. 

2.  The  formal  release  of  the  computer  program  development  specification 
and  the  computer  program  product  specification,  and  other  software 
documents  related  to  the  baselined  CPCI. 

Configuration  Control  achieved  by: 

1.  Placing  the  baselined  CPCI  under  the  control  of  a  program  support 
library  to  prevent  unauthorized  access  to  the  software  end  product, 
and  to  protect  its  integrity. 

2.  Formal  approval  of  all  changes  prior  to  incorporation. 

3.  Reidentification  of  a  new  version  of  the  CPCI  after  it  has  been  changed. 

Configuration  Status  Accounting  is  achieved  by: 

1.  Preparation,  approval  and  issuing  of  the  version  identification  list 
(or  equivalent)  to  specify  that  the  approved  changes  to  the  CPCI  and 
its  related  documents  have  been  correctly  incorporated  and  accepted. 

This  acceptance  authorization  is  normally  provided  by  a  software 
quality  assurance  function. 

The  successful  procedures  for  Viking  software  configuration  management 
have  been  adapted  for  use  on  current  software  development  projects  at 
Martin  Marietta  Aerospace,  Denver  Division. 

For  additional  information  relative  to  this  presentation,  Johm  Campbell 
may  be  contacted  at: 

Martin  Marietta  Aerospace 
Denver  Division 
P.  0.  Box  179 
Denver,  Colo.  80201 

Attn:  J.  A.  Campbell  -  Mail  Stop  0423 
Phone:  (303)  973-4592 
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PLAN 

-  MANAGEMENT  OF  CM  PROGRAM. 
PROGRAM 

-  STANDARDIZE  THE  CM  DOCUMENTS. 

-  ELIMINATE  NEED  LIMITED  COORDINATED/ 

SERVICE  PECULIAR  CM  DOCUMENTS. 


-  PROVIDE  BASIS  FOR  COST  EFFECTIVE 
IMPLEMENTATION  OF  CM. 


-  OVERALL  ASSESSMENT  OF  CM  DOCUMENTS: 

•  REGULATIONS,  INSTRUCTIONS,  ETC. 


•  STANDARDS 

•  SPECIFICATIONS 

•  DIDs 

•  DARs 

-  ASSIGNMENT  OF  TASKS  &  RESPONSIBILITIES. 

-  PROVISIONS  FOR  TAILORING/APPLICATION. 

-  PROVISIONS  FOR  MONITORING. 


BASIC  PROBLEMS: 


•  GUIDANCE  FOR  COST  EFFECTIVE  TAILORING  AND 
APPLICATION  FOR  EACH  PHASE  OF  THE  LIFE  CYCLE. 


•  OVERLAPPING,  CONFLICTING,  OVERLY  RESTRICTIVE  & 
INADEQUATE  REQUIREMENTS. 


•  COMPREHENSION  OF  CM  . 


Need  to  identify  in  front 
end  of  program. 


•  EFFECTIVE  INTEGRATION  OF  CM  WITH  OTHER 
DISCIPLINES.  Such  as  ILS  and  software. 


•  STANDARD  CM  TERMINOLOGY  &  DOCUMENTATION. 

•  EFFECTIVE  MANAGEMENT  OF  THE  PROGRAM. 


OBJECTIVES 


Accomplished: 

-  PUN  APPROVED  BY  OUSO  (R&E).  8  MARCH  1978 

•  CMAN  AREA  ASSIGNMENT  ESTABLISHED,  1  JAN  1977  (SD-1) 

•  DOD-STD-480A  PUBLISHED,  12  APR  1978 

•  NOTICE-1  TO  000-STD-480A  (TAILORING  APPENDIX]  PUBLISHED,  29  DEC  1978 

-  NOTICE-2  TO  MIL-STD -48 3( USAF )  PUBLISHED,  21  MAR  1979 

-  DOD  DIRECTIVE  5010.19  COORDINATED  AND  SUBMITTED  TO  SECDEF  FOR 
SIGNATURE,  APR  1979 

Planned: 

-  IMPLEMENT  THE  PUN 

-  UPDATE  THE  PUN  EVERY  18  MONTHS 


PROCESS  TO  IMPLEMENT  THE  PLAN 

•  DMSSB/.OUSD  (R&E)  TO  APPROVE  AND  DIRECT  (MEMO)  THE 
IMPLEMENTATION  OF  THE  PLAN  (DMSSO  MEMO  OF  9  JUNE  1978) 

•  PROMULGATE  THE  PLAN  (CNM  LTR  0423/RLB  OF  14  JULY  1978  &  28  JULY  1978) 

•  PREPARING/ PARTICIPATING  ACTIVITIES  TO  COMMENCE  TASK 
REQUIREMENTS 

•  JDCMC  TO: 

-  REVIEW  PROGRESS 

-  PROVIDE  GUIDANCE 

-  REVIEW/CONCUR  PRODUCTS  PRIOR  TO  FINAL 
APPROVAL/IMPLEMENTATION 

-  IDENTIFY/REQUEST  CORRECTIVE  ACTION 

-  PRESENT  UNRESOLVED  PROBLEMS  TO  DMSSO 
FOR  RESOLUTION 

-  REVIEW/UPDATE  PLAN  AS  REQUIRED  (MIN.  18  MOS.) 


AIR  FORCE  LESSONS  LEARNED 


MAJOR  LANCE  NESBITT 

Air  Force  Acquisition,  Logistics  Division 
Air  Force  Logistics  Command 
Wright-Patterson  Air  Force  Base 


NOTE:  This  paper  was  transcribed  from 
a  recording  of  the  session. 

Good  afternoon.  Ladies  and  Gentlemen.  Before  I  get  into  the 
"Lessons  Learned”  briefing,  I  want  to  offer  a  brief  explanation: 
Last  night  and  today,  talking  with  some  of  you,  I  found  that  a  lot 
of  you  are  not  familiar  with  Air  Force  Acquisition  Logistics  Divi¬ 
sion.  So,  I  would  like  to  take  about  a  minute  or  two  and  explain 
our  role  in  life.  We'll  be  three  years  old  this  July.  Being 
logisticians,  we  were  formed  as  an  organaztion  under  AFLC.  We  are 
assigned  to  new  programs  to  ensure  that  the  logistics  needs  are 
identified  and  satisfied  when  we  buy  new  systems  and  field  them. 
Basically,  we  obtain  our  information  through  feedback  from  our 
operators,  maintenance  personnel,  and  other  supporters  of  current 
systems.  Thus  we  have  incorporated  "Lessons  Learned"  as  part  of 
that  feedback  process. 

"Lessons  learned"  is  a  frequently  used  term.  The  definition, 
whether^applied  to  a  technical  or  to  a  management  lesson,  has  two 
important  elements:  First,  it  is  recorded?  and,  second,  it  has 
been  determined  to  be  an  experience  of  value  to  future  programs. 
Lessons  learned  is  not  any  application  of  individual  experience, 
but  rather  a  process  by  which  we  are  documenting  the  results  of 
evaluating  the  hardware  and  support  planning  of  current  systems 
and  programs.  By  applying  these  documented  experiences,  we  can 
avoid  the  mistakes  of  the  past  and  carry  forward  the  things  that 
we  have  done  right. 

After  a  short  description  of  the  purpose  of  this  briefing,  the 
methods  used  in  our  lessons  learned  process  will  be  discussed.  We 
draw  lessons  from  a  variety  of  sources  and  these  will  be  outlined. 
Our  experience  in  the  lessons  learned  business  has  shown  us  what 
lessons  can  do.  In  most  cases,  it  is  very  significant. 

The  following  is  a  discussion  of  the  current  activity  in  applying 
lessons.  Our  major  conclusions  from  a  little  over  two  years  in 
operation  will  be  discussed  also.  The  briefing  concludes  with  a 
discussion  of  what  is  needed  to  fully  institutionalize  the  applica 
tion  of  lessons  learned  and  why  we  are  here  today. 
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In  our  effort  to  analyze  and  evaluate  the  potential  lessons  learn¬ 
ed  and  identify  the  root  causes  of  current  performance  and  support- 
ability  problems,  we  have  encountered  areas  that  frankly  have  sur¬ 
prised  us.  For  example,  the  radios  on  the  F4  aircraft  were  a 
widely  publicized  lessons  learned  within  the  Air  Force.  All  our 
data  systems  showed  that  the  seat  had  a  low  reliability,  when 
really  it  was  the  radio  that  we  were  getting  after.  While  lessons 
of  that  significance  are  not  documented  every  day,  we  have  documen¬ 
ted  other  major  lessons.  This  briefing  seeks  to  highlight  some  of 
these  areas  and  point  out  the  benefit  in  applying  these  lessons. 

Now  that  our  process  has  been  through  the  new  organizational 
growth  pains,  (as  I  have  said  we  are  a  little  over  two  years  old), 
our  file  covers  a  relatively  broad  base  of  hardware  and  management 
lessons  learned.  We  are  confident  that  expanded  use  of  the  ALD 
file  can  yield  both  cost  and  supportability  benefits.  We  strongly 
advocate  the  use  of  our  service  in  the  acquisition  process  within 
the  Air  Force. 

Simply  stated,  the  method  we  employ  in  our  lessons  learned  process 
is  merely  the  classic  functions  used  in  any  information  process. 
Drawing  from  both  internal  and  external  sources,  we  have  establish¬ 
ed  a  formalized  process  to  identify  or  receive,  analyze  and  evalu¬ 
ate,  and  both  store  and  disseminate  lessons  learned.  While  we  do 
publicize  internally  within  the  Air  Force  through  abstracts  of 
what  lessons  are  on  file  and  publish  quarterly  bulletins,  the  most 
beneficial  product  to  a  program  decision-maker  is  a  pre-sorted 
tailored  package  of  lessons  learned  that  apply  to  his  program. 

In  short,  our  method  is  nothing  unique,  but  what  is  unique  is  that 
we  have  a  Directorate  organization  within  the  ALD  dedicated  to  a 
continuing  lessons  learned  function.  Another  somewhat  unique 
feature  is  that  we  have  developed  a  process  to  provide  orientation 
to  the  potential  users  of  lessons  learned.  Our  format,  key  word 
system,  and  capability  to  quickly  assemble  a  tailored  package 
covering  a  particular  subject  area  or  program  phase  are  all  geared 
to  recognize  that,  in  a  pressure-packed  environment  of  a  program 
office,  the  Deputy  Program  Manager  for  logistics  and  other 
decision-makers  don't  have  the  luxury  of  time  to  seek  out  lessons 
that  can  be  applied.  We  said  this  is  nothing  new  as  far  as  les¬ 
sons  learned.  All  programs  publish  reports  and  this  sort  of 
thing.  The  problem  is  that  they  are  untimely  for  other  programs — 
they  get  read,  filed  in  "file  thirteen"  or  put  in  somebody's 
drawer  and  forgotten.  That's  the  difference. 

Our  original  guidance  for  the  lesson  learned  system  was  that  no 
new  reporting  system  external  to  the  AFALD  would  be  created.  Our 
experience  has  confirmed  that  existing  sources  do  provide  ample 
information  to  use  in  extracting  lessons  learned.  We  have  certain¬ 
ly  experienced  no  shortage  in  source  material.  We've  have  all 
sorts  of  additional  sources  within  the  Air  Force  and  we  are  hoping 
that  maybe  industry  will  also  become  a  source  for  our  lessons 
learned. 
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One  of  our  best  sources  has  been  our  our  field  visit  program. 

Using  teams  of  from  four  to  six  people,  we  visit  base  level  activi¬ 
ties  supporting  current  systems.  We  talk  to  maintenance  techni¬ 
cians  and  supervisors  to  get  their  firsthand  experience  and  sugges¬ 
tions  for  improvement  to  future  systems.  In  addition  to  our 
equipment  technicans  from  the  lessons  learned  activity,  the  visit¬ 
ing  field  teams  may  include  individuals  from  our  ALCs  System 
Management  activities.  Item  Management  activities,  and  our  Systems 
Command  Engineering  communities.  Command  reaction  to  this  program 
has  been  good  and,  thus  far,  visits  have  been  conducted  on  A- 7, 
C-130,  FB-111  Simulators,  810,  P-38,  P-37,  B-52  and  most  recently 
the  F-15  which  we  are  just  compiling.  Reports  of  these  visits 
have  been  prepared  and  distributed,  but  the  individual  lessons  are 
also*  filed  for  use  in  preparing  tailored  or  program-phased  pack¬ 
ages  of  lessons  learned. 

Many  lessons  learned  documents  have  been  published  by  program 
offices  at  specific  points  in  time.  We  use  the  lessons  recorded 
in  these  sources  and  make  sure  that  they  are  retained  for  future 
use.  For  example,  the  F-15  Program  Office  published  an  excellent 
logistics  lesson  learned  document  in  the  spring  of  1977.  Our 
action  has  been  to  make  sure  that  this  valuable  feedback  informa¬ 
tion  is  not  lost  as  time  progresses  and  the  initial  distribution 
copies  are  filed  away. 

The  AF/ALD  Deputy  Program  Managers  for  logistics  are  another 
source  of  lessons  that  we  capture  through  yearly  reporting.  This 
was  instituted  to  make  sure  that  valuable  lessons  did  not  dim 
during  the  several  years  that  many  acquisition  programs  take. 
Inspection  and  audit  reports  are  also  another  valuable  source  of 
lessons  routinely  received  for  lessons  learned  screening. 

Internally  in  our  lessons  learned  organization,  we  initiate  vari¬ 
ous  projects  to  look  at  the  product  performance  capability  current¬ 
ly  being  experienced  by  operational  systems  and  report  it  to  our 
existing  data  systems.  For  example,  we  routinely  look  at  high 
cost  logistic  support  items  to  see  if  these  items  reveal  lessons 
learned.  Several  of  the  lessons  I  will  highlight  later  in  the 
briefing  resulted  from  this  particular  type  of  efforts. 

We  have  also  sponsored  several  lessons  learned  conferences  to  look 
at  specialized  areas  such  as  fuel  leak  problems,  erosion,  NDI,  and 
things  of  this  sort.  Through  the  publication  of  our  lessons 
learned  abstract,  we've  established  a  cross  feed  with  other  organi¬ 
zations  in  recording  lessons  from  acquisition,  engineering,  and 
test  activities.  We  draw  from  these  excellent  specialized  sources 
also.  None  of  these  activities  have  been  as  comprehensive  as  our 
efforts  and  thus  serve  to  complement  rather  than  duplicate  our 
efforts.  Utilizing  numerous  organizational  sources  helps  us 
produce  a  useful  product.  In  the  case  of  lessons  learned,  the 
value  of  the  product  is  in  its  application. 


Next  I'll  describe  some  of  the  things  lessons  learned  can  do  if 
they  are  applied.  Application  is  truly  the  bottom  line  of  the 
entire  program.  The  use  of  proven  technology  as  a  lesson  learned 
is  not  to  dictate  design  or  hinder  advance,  but,  in  some  cases,  we 
do  attempt  to  solve  nonproblems.  We  can  avoid  future  cost  by 
recognizing  the  needs  of  supportability  today.  We  also  tend  to 
support  systems  in  the  same  fashion  as  previous  systems,  because 
that  is  the  traditional  way  we  have  done  business.  Now  may  be  the 
time  to  challenge  these  traditional  ways.  Lessons  can  also  identi 
fy  problems  that  recur  from  program  to  program,  and  there  are  a 
lot  of  those.  There  have  even  been  cases  where  the  Air  Force 
induces  poor  performance  by  using  a  proven  component  in  a  differ¬ 
ent  location  and  environment.  Our  mission  needs  are  paramount  and 
systems  must  support  those  needs.  But  lessons  learned  can  point 
to  areas  where  system  features  that  are  stated  as  requirements  can 
be  challenged. 

Sample  lessons  are  the  best  way  to  illustrate  these  points  so 
those  will  be  what  I  address  next.  Virtually  every  new  aircraft 
has  tried  a  different  internal  fuel  tank  sealing  technique. 

Various  chemical  sealants  and  application  techniques  have  been 
tried,  but  nearly  every  system  has  had  fuel  leaks.  And  these  leak 
problems  have  had  an  impact  in  both  readiness  and  availability. 

In  the  base  level  maintenance  environment,  repairing  fuel  leaks  is 
a  major  maintenance  task  when  the  tank  has  to  be  opened.  After 
defueling,  purging,  and  moving  the  aircraft  to  the  fuel  cell 
repair  area,  removing  the  old  sealant  and  applying  new  is  a  time 
consuming  task  and  a  significant  contribution  to  our  maintenance 
costs.  Looking  at  the  cost  per  flying  hour  associated  with  leak 
repair,  our  engineers  hosted  a  Lessons  Learned  Conference  on  this 
particular  problem  area.  The  use  of  blind  fasteners  in  fuel  areas 
and  the  instability  of  various  chemical  sealants  were  identified 
as  problem  areas.  The  significant  lesson  was  that  the  F-106  and 
F-102  aircraft  had  a  successful  sealing  technique  using  a  thermal 
setting  bond  sealing  system  of  1950  technology.  This  system, 
known  as  Scotch  Weld,  avoids  the  problems  of  unknown  chemical 
sealants.  While  application  to  ongoing  programs  may  be  difficult, 
certainly  no  new  aircraft  program  should  be  undertaken  without 
full  consideration  of  this  major  lesson  learned. 

Another  management  lesson  learned  was  identified  in  a  program 
where  the  contractor's  claim  of  proprietary  data  rights  was  not 
challenged  while  still  negotiable.  As  a  consequence,  when  the 
need  arose  to  modify  the  aircraft  at  a  later  date,  we  were  in  a 
weak  position  to  require  the  necessary  data  to  use  in  engineering 
the  modification.  While  all  proprietary  claims  cannot  be  avoided, 
close  attention  and  challenge  can  keep  this  to  a  minimum. 

One  of  our  data  analysis  projects  involved  looking  at  high  logis¬ 
tic  support  items.  Many  of  the  top  Air  Force  support  cost  items 
are  associated  with  our  fire  control  system.  We  found  a  high 
technology  system  that  had  comparatively  high  reliability  also. 
Many  of  the  major  line  replaceable  units  used  were  changing  config 
uration  as  the  contractors  and  program  officers  sought  to  further 


mature  the  system,  a  normal  occurrence  in  avionic  systems,  but  a 
high  contributor  to  support  costs.  As  we  dug  deeper  into  the  high 
support  cost  question,  we  were  led  to  to  look  at  the  economics  of 
the  intermediate  level  of  support.  We  found  that  the  avionics 
shop  reparability  is  very  costly  and  that  the  way  the  components 
of  shop  replaceable  units  are  packaged  may  contribute  to  high 
support  costs.  In  short,  while  automated  test  equipment  is  almost 
a  necessity  for  digital  avionic  systems,  the  cost  of  the  test 
stations  themselves  may  more  than  offset  the  cost  of  additional 
spares,  if  we  would  use  a  two-level  rather  than  a  three-level 
support  concept. 

We  have  traditionally  assumed  that  if  reliability  can  be  driven 
up,  both  support  costs  and  corresponding  life  cycle  costs  will 
decrease.  What  we  are  seeing,  however,  is  that  even  with  better 
reliability,  the  cost  per  hour  is  high.  When  the  cost  of  initial 
acquisition  and  recurring  support  costs  for  the  AIS  test  equipment 
are  considered,  we  find  that  life  cycle  costs  are  also  increasing. 
While  we  are  still  wrapping  up  our  work  in  this  area,  we  find  that 
the  traditionally  assumed  performance  cost  relationships  may  not 
be  rigid,  having  several  variables  that  can  impact  the  actual 
experience  attained.  Packaging  of  the  system  should  be  fully 
considered.  If  higher  cost  integrated  system  LRV's  are  designed, 
higher  reliability  may  not  offset  the  higher  cost  accrued  when  the 
less  frequent  failures  occur.  We  also  need  to  do  a  better  job, 
considering  all  the  elements  of  life  cycle  costs,  in  selecting  our 
maintenance  concept.  We  may  now  be  at  the  point  where  we  should 
buy  more  spare  LRB's  instead  of  intermediate  test  stations  for 
each  base  maintenance  activity. 

As  our  skills  in  the  base  level  maintenance  activity  decrease,  the 
quality  of  tech  orders  takes  on  even  greater  importance.  Yet  we 
find  that  most  programs  experience  problems  in  technical  order 
development.  Technical  order  preparation  requiring  labor-inten¬ 
sive  effort  by  the  contractor  has  also  driven  the  cost  of  techni¬ 
cal  orders  up.  Pressures  in  the  contractors  organization  often 
foster  a  weak  validation  effort.  New  forms  of  technical  order 
presentation,  such  as  job  guide  manuals,  also  require  more  detail¬ 
ed  instructions  and  more  pages  of  tech  orders.  This  adds  to  the 
complexity  of  the  Air  Force  verification  of  the  data  prepared  by 
the  contractor  and,  as  a  consequence,  the  magnitude  of  the  verifi¬ 
cation  effort  is  traditionally  underestimated.  The  realization 
that  we're  behind  in  the  TO  Program  creates  pressures  to  use 
prototype  equipment  for  verifications  and  validation  with  a  result 
that  many  changes  are  needed  when  the  TO's  are  first  used  in  the 
field.  These  are  several  lessons  in  this  area.  Our  package  of 
Tech  Order  Lessons  learned  has  been  requested  more  frequently  than 
any  other  package,  which  points  out  the  complexity  and  recurriny 
nature  of  these  problems. 


The  Air  Force  has  emphasized  maintainability  for  a  number  of 
years,  yet  accessibility  continues  to  be  a  problem  area  that  we 
encounter  on  field  trips.  Lessons  learned  in  this  area  will 
certainly  be  no  panacea,  as  space  limitations  will  continue  to 
dictate  trade-off  during  the  design  process.  But  lessons  learned 
can  sensitize  this  process  to  the  more  obvious  areas  such  as 
components  requiring  repeated  service  in  inaccesible  locations. 
Lessons  learned  can  draw  attention  to  these  areas  during  design 
reviews  and  be  used  in  developing  criteria  for  systems  specifica¬ 
tions. 

It  seems  only  logical  to  avoid  inducing  problems  when  using  Govern¬ 
ment  Furnished  Equipment  (GFE).  But  we  recently  encountered  some 
lessons  learned  which  should  cause  a  more  critical  look  at  such 
components.  On  our  simulator  field  trip,  we  encountered  several 
flight  simulators  with  complex  and  costly  motion  bases  to  provide 
attitude  changes  in  the  simulator.  With  the  use  of  the  motion 
system  as  a  command  option,  some  of  these  systems  are  not  being 
used.  With  the  visual  systems  in  use  today,  motion  systems  may 
not  be  necessary  for  training  needs.  While  there  may  not  be  a 
consensus  among  the  commands  on  this  issue,  future  simulator 
programs  should  challenge  any  requirements  for  a  motion  base 
system.  In  other  words,  make  a  conscious  decision  and  identify 
the  requirement. 

The  preceding  examples  have  illustrated  some  of  the  many  lessons 
that  we  have  on  file  and  that  are  available  for  decision  makers. 

At  this  time,  we  have  somewhere  around  650  lessons  in  our  data 
bank  and  it  is  growing  at  about  50  lessons  a  month.  In  the  next 
segment  of  my  briefing,  I  will  summarize  what  is  available  in  the 
file,  who  is  currently  using  these  lessons,  and  how  they  are  being 
used . 

Very  candidly,  I  can  state  we  haven't  beaten  the  drum  too  loudly 
in  the  past  because  of  the  relatively  low  number  of  lessons  avail¬ 
able.  Our  file  has  grown  to  a  broader  base  which  expands  applica¬ 
tion  opportunities.  We  do  have  a  backlog  as  a  result  of  adding 
new  sources  and  our  high  level  of  activity.  In  the  rework  group, 
we  also  sent  a  number  back  to  the  project  offices  as  a  result  of 
our  review  process.  Our  goal  is  not  a  large  number  of  lessons, 
but  objective  lessons  that  address  the  root  cause  of  a  problem. 

For  specialized  engineering  assistance  in  evaluating  potential 
lessons,  we  have  established  working  contacts  with  our  ASDEN 
engineers.  They  have  been  particularly  helpful  in  pointing  out 
areas  that  need  to  be  considered  in  the  evaluation  of  particular 
lessons.  We  also  seek  specialized  assistance  from  our  own  engi¬ 
neers  and  other  speciality  areas  such  as  procurement,  contracts, 
etc.  As  we  add  to  our  file,  the  base  is  expanding,  but  we  are 
also  encountering  lessons  that  modify  what  is  currently  on  file. 

We  have  provided  packages  of  lessons  learned  to  Program  Offices  on 
both  a  requested  and  unrequested  basis.  Our  abstracts  have  also 
triggered  a  number  of  requests  for  packages  of  lessons.  We  have 
provided  a  number  of  packages  of  lessons  learned  to  our  Deputy 
Program  Managers  for  Logistics  and  ELSO  activities  for  application 
to  the  programs  on  which  they  are  working. 
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There  have  been  some  recent  regulations  published  within  the  Air 
Force,  in  Systems  Command,  and  in  AFLC  that  also  emphasize  their 
use  of  the  file  at  key  points  in  their  programs.  For  example,  the 
Systems  Command  regularly  requires  a  program  manager  to  come  to  us 
at  two  points  in  his  program — the  conception  and  validation  phases 
— for  program-tailored  packages.  He  must  then  identify  which 
lessons  he  has  used,  those  that  he  hasn't,  and  be  able  to  explain 
why  these  were  not  applied  to  his  program.  We  have  also  used 
lessons  in  preparing  inputs  to  program  documentation  and  in  the 
preparation  of  various  directives.  The  individual  specification 
writers  in  Systems  Command  have  also  become  good  customers  of  our 
file.  The  incorporation  of  the  lessons  learned  section  in  new 
handbooks,  which  support  the  new  Mil-Prime-Specification  concept, 
should  further  increase  this  activity. 

In  describing  the  file,  I've  already  mentioned  most  of  the  hows, 
directive  specifications,  and  program  management  decisions.  What 
we  can't  define  is  the  degree  of  use  and  whether  important  lessons 
are  being  applied.  Obviously,  not  every  lesson  can  be  applied. 
There  will  be  trade-offs.  But  a  decision  not  to  apply  should  be 
just  that--a  conscious  decision.  The  majority  of  lessons  learned 
activity  in  the  Air  Force  is  publicity  oriented.  This  is  a  pro¬ 
cess  where  lessons  are  documented  and  published  in  the  hope  that 
they  will  go  to  the  right  individual  and  be  applied.  We  think 
that  it  is  important  to  assess  the  value  of  the  feedback  process 
and  to  make  sure  that  we  are  benefiting  from  our  experience.  We 
have  willingly  provided  packages  to  any  requesting  agency  and  we 
offer  assistance  and  in  the  application  of  the  programs,  but  we 
have  had  relatively  little  feedback  of  applications.  Part  of  the 
answer  lies  in  the  awareness  and  the  ability  to  get  the  informa¬ 
tion  to  the  right  place  at  the  right  time. 

This  leads  to  our  conclusions  from  our  effort  at  this  point.  The 
number  of  ongoing  programs  at  any  given  point  in  time,  and  the 
various  phases  and  program  schedules,  make  the  coordination  of  the 
decision  and  feedback  process  a  complex  task.  Decisions  where 
lessons  can  be  applied  are  not  daily  occurrences,  but  the  deci¬ 
sions,  once  made,  cannot  often  be  changed  when  a  lesson  is  discov¬ 
ered  later.  Many  of  the  lessons  may  be  applied  solely  through 
action  to  publicize  the  information.  From  the  examples  shown 
earlier  in  the  briefing,  however,  there  are  significant  lessons 
that  should  be  considered  by  the  senior  managers  in  the  program; 
the  application  decisions  need  to  be  made  visible.  Both  of.  these 
conclusions  point  to  actions  necessary  to  fully  benefit  from  our 
investment  in  the  lessons  learned  process.  This  brings  us  to  what 
is  needed  now. 

We  in  the  ALD  are  strongly  convinced  that  the  use  of  lessons 
learned  should  become  an  integral  part  of  doing  business  in  acqui¬ 
sition  programs.  We  do  see  evidence  that  we  in  the  Air  Force  ur>- 
collectively  moving  toward  that  goal.  For  example,  we  have  recent¬ 
ly  incorporated  a  lesson  learned  review  into  the  AFLC  nodiricat  ion 


approval  process,  whereby  we  advise  configuration  control  boards 
of  lessons  learned  that  could  apply  to  a  proposed  modification. 

We  will  also  seek  to  capture  lessons  learned  from  this  process. 

Two  other  new  areas  are  the  previously  mentioned  Systems  Command 
(AFSC)  Lessons  Learned  Program  and  the  Air  Force  Feedback  Work 
Group.  While  the  Systems  Command  program  is  just  being  developed, 
it  is  compatible  with,  and  complementary  to,  our  efforts.  The 
Feedback  Working  Group  is  the  one  that  developed  the  Air  Force 
regulation  that  is  ready  to  be  published  on  feedback  and  is  much 
broader  in  scope  than  just  lessons  learned.  These  efforts  illus¬ 
trate  that  management  attention  is  being  focused  on  lessons  learn¬ 
ed  application,  but  publication  of  directives  will  not  ensure  that 
decision-makers  are  motivated  to  apply  lessons  learned.  In  parti¬ 
cular,  major  lessons,  like  fuel  sealing  methods,  planned  support 
concepts  and  objective  challenges  of  requirements  must  be  both 
emphasized  by,  and  visible  to,  top  management.  In  short,  both  the 
decision  process  and  programs,  and  the  executive  reviews  of  pro¬ 
grams,  should  focus  on  full  considerations  of  lessons  learned  in 
reaching  decisions  and,  in  effect,  imbed  lessons  learned  in  the 
decision  process. 

That  orings  us  to  why  we  were  invited  here.  Our  Commander,  Gen¬ 
eral  Albert,  recently  sent  a  letter  to  ADPA  and  offered  our  les¬ 
sons  learned  file  to  industry.  Some  of  you  have  already  seen  a 
pamphlet  on  how  to  contact  us  and  the  key  words  we  use  in  retriev¬ 
ing  our  lessons  learned.  You  can  contact  us  in  our  office.  We 
would  appreciate  first-time  contact  by  letter  specifying  the 
particular  areas  of  interest.  We  will  respond  with  copies  of  our 
lessons  learned.  One  thing  I  ask,  please  do  not  be  too  critical. 
Remember  for  whom  these  lessons  were  originally  being  made. 
Sometimes  our  English,  the  way  we  state  things,  may  not  be  the 
correct  way  of  doing  this  in  a  good  publication.  Our  management 
lessons  learned  are,  in  many  cases,  very  mundane.  They  basically 
tell  the  guy,  "Hey  I  Plan  and  execute”,  and  this  must  be  done  right 
from  the  beginning  of  your  program,  all  the  way  through.  We  found 
that  our  managers  don't  have  this  experience  and  these  things  need 
to  be  pointed  out  to  them  time  and  time  again.  So,  in  these 
areas,  those  of  you  who  have  been  in  the  business  for  many  years 
may  think,  "Hey!  That's  no  lesson  learned."  But  believe  it,  it 
is  to  many  of  our  people  in  the  acquisition  business.  If  any  of 
you  have  questions,  please  give  us  a  call  and  we  will  be  happy  to 
work  with  you.  Our  telephone  number  is  (513)  255-3222  or  -3885. 
Thank  you. 


(  AFLC I 


DEPARTMENT  OF  THE  AIR  FORCE 
heaoquarters  air  force  acquisition  logistics  division 

WRIGHT. PATTERSON  AIR  FORCE  BASE.  OHIO  45433 


27  April  1979 


General  Henry  Mi  ley,  USA,  Retired 
American  Defense  Preparedness  Association 
819  Union  Trust  Building 
Washington,  D.C.  20005 

Dear  General  Mi  ley 

The  Air  Force  is  dedicated  to  positive  action  which  will  increase  avail¬ 
ability,  supportability,  and  readiness  of  Air  Force  systems,  while  minimizing 
life  cycle  costs.  Application  of  experience  gained  from  our  deployed  systems 
is  essential  in  the  accomplishment  of  this  objective.  Prior  to  the  formation 
of  AFALD,  a  formal  mechanism  for  capturing,  storing,  and  disseminating 
logistics  experience  from  the  field  to  the  designer  did  not  exist. 

We  are  building  a  comprehensive  system  to  provide  feedback  from  the  flight¬ 
line  mechanic,  product  division,  and  experts  at  the  contracting  facilities 
to  the  designer  or  to  the  support  planning  decision  maker.  However,  we 
recognize  that  application  of  lessons  learned  is  the  essential  element.  The 
key  to  this  is  getting  into  the  acquisition  process  early  and  getting  lessons 
learned  to  those  who  influence  and  produce  design  concepts,  namely,  you  the 
contractor. 


In  order  to  improve  and  broaden  the  application  of  lessons  learned,  we  have 
opened  our  file  to  the  defense  industry.  The  attached  key  word  listing 
contains  the  terminology  used  by  the  AFALD/PTQ  to  index  and  to  retrieve  its 
lessons  learned.  It  'was  prepared  to  illustrate  the  scope  of  subjects  that 
we  currently  have  on  file  and  how  you  can  access  this  information. 

Our  lessons  learned  are  filed  in  the  form  of  a  concise,  one-page  summary 
which  can  be  disseminated  to  our  users.  This  summary  includes  a  topic,  the 
lesson  learned,  a  statement  of  the  problem,  a  discussion  of  the  example 
situation,  and  suggested  actions  to  be  taken  in  the  future.  By  use  of  key 
word  indexing,  we  are  able  to  cross  reference  by  system,  subsystem,  and 
equipment.  Currently,  the  data  is  accumulated  and  stored  manually  with  this 
key  word  capability.  We  can  easily  shift  to  an  automated  storage  and  retrieval 
system  at  a  later  time. 

We  invite  contractors  to  request  tailored  packages  of  lessons  learned  based 
on  your  areas  of  interest.  If  you  need  more  information  on  our  process  or 
the  repository,  our  commercial  number  is  (513)  255-3578.  People  who  can 
help  are:  Ms.  Jeanne  Zekowski  or  Ms.  Lana  Bailey,  AFALD/PTQS. 


Comnander 
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ENGINEERING  DRAWING  PRACTICES  DOD-D-IOOOB  and  DOD-STD-IOOC 


by 

M.  E.  TAYLOR 

Army  Armament  Research  and  Development  Command 


ABSTRACT 


This  paper  provides  an  overview  of  the  current  activities  on  Specification 
D0D-D-1000  Engineering  Drawings  and  Associated  Lists,  D0D-STD-100  Engineer 
ing  Drawing  Practices  and  DRPR  Standardization  Document  Program  Plan. 


The  subject  of  engineering  drawings  is  of  significant  interest  to  most  of 
this  audience  as  drawings  are  the  primary  element  of  engineering  documentation. 
Most  of  what  I  have  to  report  has  been  discussed  in  part  at  various  previous 
sessions  and  meetings  such  as  last  years  annual  meeting  in  New  Orleans.  There 
are  no  new  and  exciting  developments  to  report  on.  My  presentation  will  be 
essentially  a  review  of  current  status  and  what  is  in  progress  for  the  future. 
D0D-STD-100C 

The  C. Revision  of  D0D-STD-100  was  issued  under  date  of  22  December  19/8; 
however  due  to  delays  in  final  release  and  reporduction,  copies  are  just 
now  being  distributed. 

The  major  changes  were: 

a.  Updating  of  referenced  non-government  documents. 

b.  Provision  for  metric  which  is  reflected  in  the  change  in  document 
number  prefix  from  MIL-  to  DOD-  and  inclusion  of  illustration  in  metric. 
Drafting  practices  are  essentially  the  same  in  both  conventional  and  metric 
uni ts . 

c.  Addition  of  SCALE  requirements  which  were  omitted  in  the  previous 
issue. 

d.  Use  of  I  PC- D- 350  for  printed  wiring  boards. 

e.  Addition  of  list  of  materials  for  drawing  originals,  duplicate 


originals  and  reproductions. 


f.  Special  marking  for  radioactive  materials. 

g.  Revision  of  numbering  of  non-interchangeable  parts  and  up 
assemblies  to  the  practice  in  the  A  revision. 

h.  Reference  to  Code  Ident.  completely  replaced  by  FSCM. 

i.  Several  changes  to  correct  errors  and  inconsistencies. 

MIL-D-1000B  AM  1 

The  tailoring  appendix  was  approved  and  released  as  amendment  1  under  date 
of  30  November  1978.  The  guide  was  developed  at  a  series  of  government  - 
industry  meetings  with  significant  participation  by  ADPA  as  well  as  other 
interested  associations.  The  guide  is  intended  to  improve  precision  ordering 
of  only  the  data  required  and  encourage  cost  effective  counter  proposal 
from  industry.  It  is  too  early  to  have  any  significant  feedback  on  the 
utilization  of  this  document. 

DRPR  Standardization  Document  Plan 

We  are  currently  developing  a  Standardization  Document  Plan  for  the  Drawing 
Practices  Area.  This  plan,  which  will  be  coordinated  with  industry,  will 
provide  the  future  plan  of  action  for  standardization  documents  related  to 
drawing  practices.  It  is  expected  that  the  plan  will  reflect  adoption  of 
additional  non-government  documents  to  replace  portions  of  D0D- STD-100, 
simplify  and  coordinate  the  diverse  related  Data  Item  Descriptions,  and 
provide  some  guidance  in  the  emerging  technology  areas  such  as  micro  circuits 
which  are  not  adequately  addressed  in  the  current  standards. 


You  will  be  provided  an  opportunity  to  ask  questions  and  discuss  these  and 
related  documents  at  the  Drawing  Workshop  planned  for  tomorrow  afternoon. 
Comments  and  suggestions  of  both  D0D-D-1000  and  D0D-STD-100  are  invited  and 


may  be  submitted  on  the  DD  1426  form  attached  to  the  documents. 


JOHN  D.  COOPER 


ANCHOR  SOFTWARE  MANAGEMENT,  LTD. 


SUMMARY 

Several  misconceptions  or  myths  about  some  facets 
of  software  have  evolved  over  the  years.  This  paper 
addresses  five  of  these  myths  attempting  to  expose 
them  and  put  them  in  their  proper  perspective.  Subject 
of  the  myths  are  Programming  Languages,  Structured 
Programming,  Documentation,  Flow  Charts  and  Firmware. 


SOME  SOFTWARE  MISCONCEPTIONS  (MYTHS)  EXPOSED 


INTRODUCTION 

I  would  like  to  use  the  next  20  minutes  to  tackle  head-on 
five  misconceptions,  or  more  appropriately  myths,  concerning 
software  that  are  still  today  bouncing  around  the  industry. 

Like  most  of  mythology  there  was  a  certain  amount  of  truth 
surrounding  the  origin  of  these  myths.  However,  I  hope  to  be 
able  to  convince  you  that  they  are  today  a  great  deal  more 
fiction  than  fact. 

! 

PROGRAMMING  LANGUAGES 

I  ■■  — 

The  first  myth  to  be  debunked  is  that  "machine  oriented 
^  languages  are  more  efficient  than  high  order  languages". 

Assembly  languages  represent  the  most  common  example  of  machine 
oriented  languages  or  MOLs.  COBOL,  FORTRAN,  CMS-2  and  JOVIAL 
are  examples  of  high  order  languages  or  HOLs. 

Figure  1  gives  a  simple  example  of  a  program  statement 
written  in  an  HOL  and  then  shows  its  MOL  equivalent.  Note  the 
HOL  reads  almost  like  English  while  on  the  other  hand  the  MOL 
is  like  so  much  gobbledy  gook.  Which  would  you  rather  read, 
learn  to  use,  decipher  or  maintain? 

The  myth  statement  was  generally  true  in  the  very  early 
days  of  HOLs  when  the  first  compilers  were  often  very  inefficient 
and  all  programmers  were  skilled  in  the  use  of  machine  code  or 
assembly  language.  (Efficiency  being  measured  in  terms  of 
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memory  utilization  and  speed  of  execution.)  Today  the  state¬ 
ment  is  true  only  when  used  by  an  expert  assembly  language 
programmer.  Only  5  percent  of  the  programmer  labor  force  is 
estimated  that  fall  into  this  category.  There  just  aren't 
that  many  programmers  around  that  can  out-perform  a  compiler 
which  was  implemented  by  a  real  expert.  The  myth  is  definitely 
false  when  the  MOL  is  in  the  hands  of  the  average  programmer 
of  the  industrial  labor  force. 

There  is  another  caveat  that  must  also  be  applied.  Even 
in  the  hands  of  an  expert,  the  myth  is  only  true  when  the 
programs  are  small  and  highly  modular.  This  is  due  to  the 
limitation  of  the  human  mind  to  remember  and  keep  track  of  the 
myriad  of  details  involved  in  assembly  language  programming. 

Things  like  the  content  of  all  registers  at  all  times, 
addresses  and  contents  of  temporary  storace  areas,  status  of  variou. 
input  and  output  activities,  and  so  forth.  The  scope  of  all 
this  type  of  technical  detail  must  be  restricted  to  small 
programs  in  order  for  the  programmer  to  out-perform  a  compiler 
with  comparative  limitless  remembrance. 

Have  you  ever  heard  of  a  programmer  who  didn't  think  his 
program  was  critical  to  operation  of  the  system  or  of  a  program 
manager  who  didn't  maintain  that  he  was  suffering  under  severe 
memory  and  processor  time  constraints?  This  sort  of  rationale 
is  used  to  justify  the  use  of  an  assembly  language.  There  is 
a  lot  of  data  to  support  the  fact  that  both  persons  are  wrong 
about  95%  of  the  time.  For  example,  a  well  known  rule  of  thumb 
says  that  5%  of  the  code  performs  95%  of  the  work. 


There  are  other  reasons  too.  MOL  usage  is  promoted  by 
contractors  because  the  resulting  obscure  programs  enhances 
contract  security.  How  can  the  development  be  monitored  when 
the  MOL  code  is  as  unintelligible  as  that  in  the  Figure  1 
example?  MCL  usage  is  further  promoted  by  the  programmers 
because  his  obscure  code  means  job  security.  There  is  no 
way  to  supervise  his  progress  and,  worse  yet,  there  is  no 
way  to  replace  him.  No  one  could  ever  read  or  understand  his 
code . 

Now  let's  re-define  efficiency  in  terms  of  development 
costs;  which  is  very  important  since  software  is  so  labor 
intensive.  Take  a  look  at  Figure  2.  The  advantages  of  HOL 
against  MOL's  are  compared.  If  you  were  the  program  manager, 
or  better  yet,  the  customer,  which  would  you  rather  be  used? 

The  first  two  MOL  advantages  shown  there  have  been  discussed. 
The  next  three  are  sometime  necessities  but  certainly  not  valid 
reasons  for  writing  the  whole  program  in  MOL.  Finally,  optimi¬ 
zation  is  a  more  ligitimate  use  of  MOL.  The  proper  thing  to 
do  is  first  write  the  whole  program  in  HOL,  then  with  monitors 
locate  the  5%  of  the  code  that's  using  95%  of  the  processor's 
time  and  then  perhaps  re-writing  that  code  in  MOL  may  prove 
cost  effective. 

MCL's  really  aren't  more  efficient  than  HOL's  when  all 
factors  are  considered.  But  you  would  be  surprised  how  many 
new  development  projects  are  still  using  MOL's.  The  time  is 
over-due  for  recognizing  the  mythology  involved  and  step  into 
today's  world  of  HOL's. 


STRUCTURED  PROGRAMMING 


The  next  myth  says  that  "The  use  of  Structured  Programming 
results  in  very  inefficient  code".  Structured  programming  came 
along  in  the  early  seventies  and  it  encountered  the  natural 
phenomenon  of  the  resistance  to  something  new  or  to  change. 

Also  the  "this  ain't  the  way  we've  always  done  it"  syndrome 
helped  to  retard  its  acceptance.  Structured  programming  required 
some  re-thinking  on  the  part  of  veteran  programmers.  Inertia 
was  difficult  to  overcome.  The  almost  universal  argument  against 
its  use  was  that  it  would  result  in  inefficient  programs. 

Structured  programming  means  different  things  to  different 
people.  Basically  it  is  a  collection  of  good  software  engineer¬ 
ing  techniques.  It  includes  not  only  the  use  of  a  limited 
set  of  control  structures  but  also  other  things  such  as:  small 
and  independent  modularity;  only  one  entry  and  one  exit  per 
unit  of  code;  use  of  stubs;  use  of  design  and  code  walk-thru's; 
and  readable  code.  While  these  procedures  are  all  very  beneficial, 
the  single  most  important  facet  of  structured  programming  is 
the  discipline  that  it  introduces  into  the  software  development 
process.  Up  to  this  point,  software  development  had  been  charact¬ 
erized  by  a  lack  of  discipline.  There  is  a  natural  tendency  to 
resist  a  sudden  curtailment  of  liberties,  ie.  discipline. 

Some  people  were  so  convinced  that  structured  programming 


was  inefficient  that  they  set  out  to  prove  it  mathematically. 
They  succeeded  too.  There's  a  problem  with  that  though. 
Structured  programming  is  less  efficient  only  when  compared  to  a 


perfect  program!  I  don't  know  very  many  people  who  write 


perfect  programs.  Especially  the  type  of  contract  programmers 
who  are  used  to  mass  produce  software  for  the  government,  I 
don't  believe  write  perfect  programs.  I  contend  then  that 
structured  programming  does  not  result  in  inefficient  programs 
of  the  type  sold  to  the  government. 

Actual  experience  bears  me  out.  If  it  were  really  inefficient 
then  no  one  would  be  using  it,  especially  the  aerospace  or  defense 
industry.  I  don't  know  of  any  companies  who  are  not  claiming 
to  use  structured  programming  —  do  you?  Almost  all  government 
contracts  in  one  way  or  another  require  it.  The  Air  Force’s 
Space  and  Missile  Systems  Office  (SAMSO)  and  Rome  Air  Development 
Center  ( RADC)  have  both  been  specifying  its  use  for  a  long  time. 
Mil-Std-1679  entitled  "Weapons  System  Software  Development"  is 
steeped  in  structured  programming.  If  structured  programming 
were  as  bad  as  some  people  would  have  us  believe,  then  it  would 
not  have  that  kind  of  support. 

Even  if  the  good  software  engineering  procedures  and  tech¬ 
niques  were  not  involved,  the  disciplinary  effect  that  structured 
programming  exerts  over  the  software  development  process  makes 
it  all  worthwhile.  During  my  time  in  the  DOD  software  business, 

I  never  saw  a  contract  that  required  an  elegant  or  a  creative 
or  a  heuristic  program.  They  weren't  looking  for  esoteric  soft¬ 
ware,  they  wanted  programs  that  satisfied  the  requirements,  that 
worked,  that  came  in  within  cost  and  schedule  constraints  and 
that  were  maintainable.  Even  if  structured  programming  was  some¬ 
what  inefficient  in  terms  of  space  and  speed,  the  discipline 
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would  more  than  counter-balance  that  and  make  its  use  cost 
effective . 

Were  you  able  to  think  of  a  company  who  didn't  use 
structured  programming?  If  you  did  —  I’ll  bet  that  in  three 
years  from  now  they  won't  be  in  the  business  of  selling  soft¬ 
ware  to  the  government.  They  can't  be  competitive  in  producing 
their  software.  It's  time  that  all  the  artificial  resistance 
to  structured  programming  be  dissipated  and  the  business  of 
developing  software  with  a  positive  attitude  be  gotten  on  with. 

DOCUMENTATION 

A  common  software  related  whipping  boy  or  Shmoo  is  computer 
program  documentation.  Too  often  it  is  just  thought  of  in  terms 
of  the  paper,  ink,  technical  writing,  typing  and  publishing. 

A  lot  of  people,  especially  the  unenlightened,  think  it  fashion¬ 
able  or  smart  to  assert  that  the  cost  of  documentation  is  excessive. 
While  a  certain  amount  of  that  assertion  is  true,  it  is  certainly 
not  true  within  the  context  of  their  implication. 

Documentation  also  gets  a  bum  rap  from  programmers.  Document¬ 
ing  a  program  is  the  last  thing  a  programmer  wants  to  do.  He  will 
go  to  all  sorts  of  extremes  to  get  out  of  that  distasteful  chore. 
They  hate  to  do  it.  Consequently,  they  defame  it  at  every  oppor¬ 
tunity.  Their  heart  is  not  in  their  work  and,  thus,  they  don't 
try  to  do  a  good  job. 

Ask  yourself  what  is  computer  program  documentation. 
Documentation  is  the  physical  manifestation  of  all  aspects  of  a 
computer  program.  It  is  the  vehicle  for  the  delivery  or  a  program. 
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It  is  the  statement  of  requirements  for  a  program.  It  is  the 
detailed  description  of  the  design  of  a  program.  It  comprises 
the  baselines  for  configuration  management.  It  is  the  vehicle 
for  change  control.  It  is  a  maintenance  tool.  It  is  the 
operator's  manual  and  the  user's  instructions.  And  so  on. 

If  you  were  not  allowed  to  buy  any  documentation  or  you 
inherited  a  program  that  didn't  have  any.  I'll  bet  you  ulti¬ 
mately  would  be  willing  (as  well  as  required)  to  spend  a  lot 
of  money  to  obtain  this  necessary  tool  for  the  aforementioned 
functions.  Of  all  its  many  uses,  some  of  which  were  mentioned 
earlier,  let's  examine  on^  program  design,  in  a  little  more 
detail.  When  a  large  software  system  is  developed,  a  great 
deal  of  effort  goes  into  its  design.  How  is  this  design 
committed  to  posterity?  How  is  the  effort  charged  to  the 
customer?  The  computer  program  design  specification  document 
is  the  vehicle  for  these  activities.  The  developer  should 
formalize  the  design  of  a  program  rather  than  doing  it  in  an 
ad  hoc  manner  on  the  fly,  using  the  back  of  envelopes.  The 
customer  should  be  willing  to  pay  for  the  design  of  his  program, 
remembering  that  a  good  design  is  more  expensive  than  the 
programming  by  a  factor  of  at  least  two.  Yet  the  program  design 
document  is  nearly  always  criticized  for  being  too  expensive. 

The  cost  is  not  for  the  paper  and  ink  of  which  the  document  is 
composed,  it's  for  the  effort,  time,  creativity,  etc.  that 
goes  into  the  design. 


If  you  examine  all  the  other  necessary  functions  served 


by  documentation  in  light  of  their  proportionate  share  of 
the  software  development  effort  and  their  contribution  to 
the  software  development  and  maintenance  processes,  you  will 
find  that  they  too  are  not  really  as  expensive  as  the  current 
mythology  would  lead  you  to  believe.  How  much  is  a  good 
statement  of  requirements  worth?  What  else  would  you  use  for 
configuration  management?  Good  operator,  user,  and  mainten¬ 
ance  documents  are  worth  their  weight  in  gold.  Exact  values 
for  these  services  and  uses  cannot  ever  be  obtained  but  we 
know  they  are  not  as  expensive  as  the  consequences  of  either 
poor  or  missing  documentation.  They  also  are  all  orders  of 
magnitude  less  expensive  when  obtained  concomitant  with  the 
software  development  process  rather  than  when  they  must  be 
reconstructed  after  the  fact. 

Yet  on  the  other  hand,  computer  program  documentation  does 
cost  a  little  more  than  it  should.  It  is  like  its  attendant 
computer  program  -  labor  intensive.  Researchers  have  long 
sought  the  Holy  Grail  of  a  better  way  to  document  computer 
programs.  Admittedly  the  English  language  is  very  poor  for 
this  purpose  but  at  this  point  it's  all  we've  got.  Lacking  a 
better  vehicle,  we  can  at  least  try  to  reduce  the  amount  of 
labor  (thus  the  cost)  involved  by  somehow  automating  the 
document  creation  process. 

This  myth  that  documentation  is  excessively  expensive 


must  be  laid  to  rest.  It  is  often  the  cause  of  some  of  a 


project's  problems.  It  creates  the  mentality  that  results 
in  the  documentation  being  the  first  item  cut  when  the  project 
experiences  a  budget  cut  or  a  cost  over-run.  Since  documenta¬ 
tion  turns  out  to  be  necessary,  then  that  tactic  turns  out  to 
be  penny  wise  and  pound  foolish.  Good  documentation  is  cost 
effective . 

FLOW  CHARTS 

The  next  myth  says  that  "flow  charts  are  an  absolute 
necessity  for  life  cycle  maintenance  of  software".  This  think¬ 
ing  is  similar  to  that  perpetuating  some  of  the  other  myths  - 
unenlightened.  In  the  early  days  of  the  software  industry, 
flow  charts  were  as  sacrosanct  as  motherhood.  The  myth  was 
given  a  new  lease  on  life  when  automatic  flow  charts  came  along 
Now  flow  charts  could  be  generated  not  only  automatically  but 
very  accurately  and  cheaply  as  well. 

In  some  ways  the  advent  of  auto-flow  charters  was  the 
beginning  of  the  end  for  all  flow  charts.  The  first  thing  the 
auto-flow  charters  did  was  to  prostitute  the  primary  purpose 
of  flow  charts.  Flow  charts  were  originally  intended  to  help 
a  programmer  by  the  use  of  symbols,  to  organize  the  logic  flow 
of  his  program.  He  first  designs  his  program,  then  uses  a 
flow  chart  to  develop  the  logic  flow  and  then  as  a  final  step 
he  codes  his  program  according  to  his  flow  chart.  Auto-flow 
char ters  can '  t  be  used  until  the  coding  is  completed  because 
they  work  from  program  source  code.  Thus,  manual  flow  charts 


are  still  required  and  the  automatic  ones  are  a  redundancy. 
Redundancy  is  never  cheap.  Automatically  generated  flow 
charts  are  very  accurate  -  yes,  until  the  code  is  changed  and 
the  program  is  not  completely  flow  charted  again. 

Also  helping  sound  the  death  knell  for  flow  charts  was 
that  the  automatically  generated  ones  amplified  the  complexity 
in  their  construction  and  use.  The  many  off-page  connectors 
result  in  a  tremendous  amount  of  page  flipping  back  and  forth. 
This  destroys  a  person's  train  of  thought  as  well  as  being  a 
rather  large  bother. 

Perhaps  we  have  digressed.  The  myth  says  that  flow 
charts  are  necessary  for  the  maintenance  of  software.  Recall 
that  a  real  flow  chart  is  generated  prior  to  coding.  The  code 
that  represents  that  flow  chart  will  be  changed  many,  many 
times  before  that  program  is  established  in  its  final  field 
environment.  Thus,  there  is  no  way  that  flow  chart  can  be 
used  by  a  maintainer  to  help  him  decipher  the  program's  logic 
and  code . 

On  the  other  hand,  automatically  generated,  after-the-fact 
flow  charts  faithfully  represent  the  program's  logic  and  code. 

I  wouldn't  bet  on  it!  Again,  that's  only  true  if  the  program 
had  been  completely  flow  charted  after  its  last  program  change. 
It  costs  money  even  for  the  automatic  type  of  flow  chart,  not 
to  mention  the  other  logistical  considerations  of  time,  bother, 
configuration  management  of  the  flow  charts,  distribution,  etc. 
The  people  with  the  money  just  don't  like  to  spend  it  that  way. 


Consequently,  the  flow  charts  get  re-done  after  some  arbitrary 
number  of  changes  in  the  code,  if  ever  at  all.  The  bottom 
line  is  that  the  maintenance  programmer  doesn't  know  whether 
the  flow  chart  is  current  or  not.  He  can't  trust  them. 

What  good  is  the  flow  chart  if  the  maintenance  programmer 
lacks  confidence  in  them  and  won't  use  them?  They  are  just  a 
waste  of  money  and  effort  as  far  as  he's  concerned.  His  job 
is  hard  enough  without  spending  hours  or  even  days  on  some 
wild  goose  chase  brought  about  by  an  inaccurate  flow  chart. 

The  flow  chart's  coup  de  grace  was  rendered  by  structured 
programming.  The  structured  programming  restrictions  on  logic 
flow  obviated  the  need  for  flow  charts  in  the  traditional 
form  described  by  the  ANSI  standard.  There  have  been  six  or 
seven  attempts,  such  as  "Chapin  Charts",  to  devise  an  alternate 
graphic  or  symbolic  way  to  represent  the  logic  of  a  structured 
program.  None  so  far  have  gained  any  significant  amount  of 
acceptance.  Since  every  reputable  company  in  the  industry  is 
using  structured  programming,  the  only  requirement  for  the 
traditional  type  of  flow  chart  is  an  artificial  one. 

It  is  now  time  for  the  flow  chart  requirement  to  be  laid 
to  rest.  This  requirement  is  a  hold  over  from  earlier  times 
and  which  is  being  perpetuated  by  the  unenlightened  who  are 
reluctant  to  cut  them  loose.  Flow  charts  are  a  big  cost  driver 
In  this  time  of  increasing  costs  of  software  and  documentation, 
flow  charts  represent  an  unnecessary  expense  that  can  be  done 
away  with. 


FIRMWARE 


Our  final  myth  is  also  the  most  recent  one.  Mythology 
has  it  that  firmware  is  some  kind  of  special,  unique  beast. 

As  a  consequence,  all  sorts  of  new  procedures  and  techniques 
are  being  discussed  and  proposed  for  dealing  with  firmware. 
Attend  most  any  of  the  industrial  computer  workshops  and  you 
will  find  several  panels  dealing  with  some  facet  of  firmware. 
Some  of  the  topics  in  vogue  are:  What  is  the  proper  way  to 
document  firmware?  Are  high  level  languages  appropriate  for 
developing  firmware?  And,  is  firmware  really  software  or 
hardware? 

What  is  firmware?  Answering  this  question  will  go  a 
long  way  toward  putting  firmware  in  proper  perspective. 

First,  firmware  can  be  defined  as:  "The  logical  code  (micro¬ 
instructions)  of  computer  equipment  which  interprets  the  control 
functions  (microprogram)  of  that  equipment."  Within  that 
definition  fall  two  different  types  of  firmware,  depending  upon 
the  form  of  their  residence  inside  the  computer.  One  type 
resides  in  what  is  commonly  called  writeable  control  store. 

The  microprogram  for  this  type  is  read  into  the  computer  and 
executed  just  like  any  other  computer  program.  The  other  type 
of  firmware  usually  resides  in  a  semipermanent  form  of  memory 
like  PROMS  and  EPROMS. 

From  that  definition,  it  should  be  clear  that  firmware 
is  really  nothing  but  software.  It  is  merely  a  more  primitive 
form  of  computer  instructions  than  is  normal  machine  language. 


The  microinstructions  are  arranged  in  a  sequence  that  results 
in  a  computer  program  just  like  machine,  assembly,  or  high 
order  language  instructions.  Microprograms  are  designed, 
developed,  and  tested  just  like  any  other  software  packages. 

In  fact,  it  is  developed  in  the  software  factory  and  many  of 
the  same  tools  are  used.  Firmware  is  software  and  it  should 
be  treated  accordingly. 

The  only  form  of  firmware  that  deserves  special  mention 
is  that  type  that  resides  in  PROMs.  Because  of  the  inflexi¬ 
bility  of  this  form,  final  testing  is  more  critical.  Even 
this  form  of  firmware  is  software  up  until  the  instant  the 
microprogram  is  burned  into  the  PROM.  After  burn-in,  it  is 
just  like  any  other  item  of  hardware  and  should  be  treated 
accordingly.  It  is  this  type  of  firmware  that  has  caused 
the  consternation.  But  really  it's  software  and  then  hardware 
not  some  special,  unique  beast. 

Due  to  its  rather  primitive  form,  firmware  does  merit 
some  special  consideration.  It  should  not  be  considered  a 
separate  engineering  process.  It  is  merely  another  form  of 
software.  The  firmware  myth  is  not  as  deeply  entrenched  as 
the  other  myths.  Hopefully  it  will  then  be  easier  to  dispose 
of  this  one. 
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SUMMARY 


In  summary,  my  goal  was  to  expose  five  common  software 
related  misconceptions  or  myths  and  place  the  attendant 
notions  into  proper  perspective.  Myths  and  misconceptions 
survive  only  in  a  recondite  environment.  By  bringing  them 
out  in  the  open  and  examining  them  critically,  their 
creditability  tends  to  dissipate  quickly. 

The  use  of  high  level  programming  languages  really  is 
a  lot  more  cost  effective  than  using  assembly  languages. 

That's  why  they  were  invented  and  why  they  have  survived. 

The  resultant  discipline  of  structured  programming  has  been 
extremely  contributory  in  reducing  the  cost  of  developing 
software.  Structured  programming  has  been  the  only  signifi¬ 
cant  advance  in  the  software  state-of-the-art  in  the  last 
twenty  years.  Computer  program  documentation  is  essential 
to  all  aspects  and  phases  of  the  software  life  cycle.  Its 
costs  are  commensurate  with  its  utility  and  when  viewed  in 
that  manner,  are  not  especially  out  of  line.  Flow  charts 
are  a  relic  from  days  gone  by.  They  are  no  longer  (if  they 
ever  were)  useful.  To  continue  to  insist  upon  their  creation 
is  just  not  cost  effective.  Firmware  is  not  some  new  mysterious 
technology,  it  is  software.  Once  this  is  recognized,  it  easily 
can  be  dealt  with. 

Today  is  not  soon  enough  to  remove  the  mythology  from 
the  software  development  and  acquisition  processes  and  get  on 
with  the  business  of  producing  high  quality  software  in  the 
most  economical  way. 
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PRINTED  WIRING  SPECIFICATIONS  AND  STANDARDS 

DIETER  BERGMAN 
Technical  Director,  IPC 

NOTE:  This  paper  was  transcribed  from 
a  recording  of  the  session. 


I  am  very  pleased  to  be  here.  I  was  also  pleased  to  see  that  when 
I  got  my  rental  car,  it  was  not  subject  to  the  odd-even  thing  at 
the  gas  station.  The  IPC  is  located  in  Evanston,  Illinois  and  we 
watch  the  situation  out  here  very  carefully.  We  had  our  share  of 
problems  this  winter,  as  most  of  you  know.  Maybe  if  our  Mayor 
Berlandi  could  have  done  something  with  the  snow  as  Governor  Brown 
did  with  the  gas  he  would  still  be  mayor. 

Anyway,  today  I  would  like  to  talk  to  you  about  MIL-STD-275,  cover¬ 
ing  the  design  of  printed  boards;  MIL-P-55110,  for  the  procurement 
of  bare  boards;  and  MIL-P-28809,  for  assemblies. 

Before  I  start  on  the  specifications  you  should  know  as  most  of 
you  do,  I  work  for  IPC.  We  go  by  the  initials  IPC  which  used  to 
stand  for  Institute  of  Printed  Circuits.  A  few  years  ago  we 
changed  our  name,  but  kept  our  initials.  The  logo  IPC  was  well- 
known  throughout  the  world  in  printed  wiring  applications.  They 
wanted  to  keep  that,  but  the  name  is  now  Institute  for  Intercon¬ 
necting  and  Packaging  of  Electronic  Circuits.  We  try  to  avoid 
using  the  whole  name  and  just  go  by  the  initials.  The  reason  I 

mention  this  is  that  IPC  has  gotten  involved  in  the  interconnec¬ 

tion  of  electronic  components.  We  have  committees  on  hybrids, 
discrete  wiring,  back  planes,  and  things  of  that  nature.  Because 
our  main  forte  was  printed  wiring,  we  did  become  involved  in  the 
use  of  military  specifications  that  affect  printed  wiring  boards. 

In  1976,  the  Defense  Electronics  Supply  Center  (DESC)  called  IPC 

and  asked  us  to  work  with  them  a  little  differently  from  the  way 

we  had  in  the  past  to  develop  changes  to  the  existing  printed 
board  specifications.  I  don't  know  how  many  of  you  are  familiar 
with  the  way  specifications  were  created,  but  at  that  time  we  used 
to  get  a  contract  from  the  Government  and  one  company  would  devel¬ 
op  what  they  felt  the  Government  wanted.  This  was  then  circulated 
throughout  Industry  and  was  followed  by  coordination  meetings. 

These  meetings  were  often  three  days  of  continual  arguement  be¬ 
tween  Government  and  Industry  members.  That  was  a  pretty  fruit¬ 
less  kind  of  activity.  When  DESC  asked  if  we  could  do  something 
different,  we  suggested  creating  a  group  consisting  of  eight  repre¬ 
sentatives,  tried  and  true,  from  Industry  and  eight  representatives 
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of  the  Services.  This  group  would  be  locked  in  a  room  for  three 
days  to  develop  a  proposed  revision.  At  IPC,  we  put  together  a 
blue  ribbon  committee  made  up  of  industry  experts.  They  repre¬ 
sented  the  large  manufacturing  companies  (ones  that  have  captive 
shops) ,  as  well  as  independent  manufacturers  that  supply  boards  to 
industry.  We  got  in  those  eight  people  a  relatively  good  cross- 
section  of  industry.  The  military,  of  course,  was  represented  by 
the  Army,  Navy,  Air  Force,  National  Security  Agency,  and  also  the 
Missile  Command. 

It  was  very  interesting — you  put  all  these  people  in  a  room  and 
took  off  their  hats,  and  you  really  couldn't  tell  who  was  a 
Government  person  and  who  was  an  industry  person.  The  exercise 
was  one  of  "let's  see  what  we  can  do  to  come  up  with  the  very  best 
concept  that  would  be  fair  to  someone  who  was  buying  boards  and 
someone  who  was  making  boards."  An  interesting  note  is  that  one 
of  the  individuals  who  was  from  industry  had  a  completely  differ¬ 
ent  attitude.  He  wanted  to  do  very  little  testing  because  he  felt 
that  he  was  a  good  quality  house.  When  I  said  to  him  "Hey,  Jim, 
what  if  you  have  to  buy  boards?",  he  said,  "Oh,  then  I  want  this, 
this,  and  this."  So  I  guess  it  depends  where  you  sit. 

Anyway,  this  concept  has  worked  pretty  well  in  revising  MIL-STD- 
275  and  MIL-P-55110.  We  have  just  finished  doing  the  same  thing 
with  the  raw  material  specif ications.  Some  of  you  may  have  al¬ 
ready  gotten  copies  of  MIL-P-13949  which  now  combines  all  the  raw 
materials  used  in  printed  boards.  We  are  now  starting  on  MIL-P- 
28809,  the  assembly  document.  Although  it  has  existed  for  several 
years,  it  has  not  been  revised  in  light  of  the  latest  changes. 

Anyway,  back  to  MIL-STD-275  and  MIL-P-55110:  This  group  met, 
looked  at  the  documents,  and  decided  that  we  would  combine  every¬ 
thing  that  existed  for  rigid  boards  into  three  specifications.  A 
design  specif ication  which  would  define  three  types  of  boards; 

Type  1  being  single-sided.  Type  2  being  double-sided,  and  Type  3 
being  multilayer.  MIL-STD-275  would  contain  the  design  require¬ 
ments,  MIL-P-55110  would  cover  single,  double,  and  multilayer 
boards,  and  MIL-P-28809  already  contained  assembly  requirements 
for  the  three  board  types.  So  what  our  industry  has  now  is  three 
basic  documents. 

What  I  would  like  to  do  this  afternoon  is  go  over  briefly  some  of 
the  things  that  created  the  most  discussion  during  these  meetings. 
(We  met,  as  I  recall,  in  June  1976  and  in  December  1976.  A  draft 
was  sent  out  to  industry  early  in  1977,  a  coordination  meeting 
held  in  mid  1977,  and  the  two  documents  were  released  early  last 
year.)  In  many  instances,  industry  made  compromises  and  the  Ser¬ 
vices  made  compromises.  I  would  like  to  give  you  a  little  benefit 
of  some  of  those. 


The  scope  of  MIL-STD-275  establishes  it  as  a  standard  for  rigid 
boards  only.  (The  plan  is  that  at  some  time  in  the  future  there 
will  be  a  design  specification  for  flexible  printed  wiring,  but 
for  now  we're  talking  only  about  rigid.)  In  addition  to  that, 
MIL-STD-275  is  for  rigid  boards  that  are  conformally  coated  after 
the  components  have  been  inserted. 

With  that  in  mind,  let's  look  at  the  content  of  the  document. 

There  are  four  major  sections  in  this  document  with  which  you 
should  concern  yourself  .  Section  4  has  the  general  requirements. 
Section  5  has  the  detail  board  requirements,  and  Section  6  the 
requirements  for  assembly  of  components. 

The  document  gets  right  to  the  heart  of  the  problem  in  paragraph 
4.1  under  General  Requirements,  where  it  requires  that  a  quality 
conformance  test  coupon  shall  be  included  on  the  master  pattern, 
master  drawing,  and  artwork.  Now  this  is  new;  we  really  never  had 
to  do  this  before.  When  we  provided  the  procurement  package  to 
the  Government  with  an  outline  of  the  board  or  the  circuit  config¬ 
urations,  we  never  had  to  define  a  test  coupon.  The  new  MIL-STD- 
275  has  two  test  coupons  defined  therein;  one  for  single  and 
double-sided  panels  and  the  other  for  multilayer  panels.  They 
state  in  the  document  that  you  shall  have  at  least  one  quality 
conformance  coupon  on  each  panel.  Our  industry  builds  panels,  not 
boards.  The  Government  is  very  concerned  that  they  have  some 
assurance  when  they  inspect  a  coupon  that  it  is  representative  of 
the  board. 

At  this  point  in ' the  meetings,  we  got  into  some  discussions  about 
how  coupons  are  normally  applied.  One  member  said,  "Well,  you 
know  we  get  the  artwork,  we  reduce  it,  make  a  master  pattern,  and 
and  look  at  it.  When  that's  all  pretty  good,  we  get  some  tape  and 
tape  the  coupon  onto  the  master  pattern  and  we  make  our  production 
run."  Well  if  I  were  going  to  buy  boards  and  look  at  the  coupon 
to  verify  registration,  I  wouldn't  be  very  h.«ppy  if  it  was  just 
taped  on.  So  the  statement  was  put  into  the  new  standard  that 
when  you  create  a  master  pattern,  you  define  where  the  quality 
performance  coupon  shall  be.  When  you  are  dealing  with  several 
vendors  this  may  get  a  little  tricky.  Since  you  don't  know  how 
many  boards  per  panel  will  be  built  or  what  the  total  panel  size 
is,  your  documentation  should  be  general  enough  to  give  him  two  or 
three  possible  coupon  locations  in  relation  to  your  single  board 
image.  You  need  to  discuss  with  your  suppliers  how  they  are  going 
to  handle  the  coupon  on  a  panel  basis.  There  is  a  figure  in  the 
new  -275  that  makes  some  suggestions,  but  the  basic  criterion  is 
that  the  coupon  must  be  representative  of  the  board  that  is  being 
inspected . 

MIL-STD-275  still  talks  about  the  master  drawing  and  says  things 
like,  "The  size  and  shape  of  all  features,  holes,  and  lands  shall 
be  adequately  dimensioned."  However,  there  is  a  basic  new 
paragraph  that  has  been  added.  It  says  that  you  will  specify  on 
the  master  drawing  those  manufacturing  allowances  that  you  include 
in  the  design  when  you  first  develop  the  drawing  package.  Let  me 
tell  you  the  reason  for  that. 


In  our  industry,  we  have  the  problem  where  one  company  had  the 
development  contract  and  the  Government  had  bought  ten  boards.  It 
would  then  go  to  another  company  for  the  production  quantities, 
and — lo  and  behold — the  boards  couldn't  be  built  from  the  same 
artwork.  This  was  primarily  because  somebody  had  underdesigned  or 
that  the  minimum  annular  ring  requirements  were  not  really  consi¬ 
dered  or  that  the  manufacturing  allowances  considered  in  the 
design  were  not  adequate.  If  you're  building  boards  that  you  have 
designed,  you  can  be  very  careful  with  a  certain  set  of  holes  if 
you  know  they  are  a  problem  to  you.  The  next  guy  that  gets  that 
information  doesn't  know  it,  so  he  starts  building  scrap.  Of 
course,  the  Government  has  to  pay  for  that.  As  taxpayers,  we 
eventually  pay  for  it.  So  the  new  -275  requires  you  to  specify  on 
the  master  drawing  what  allowances  have  been  used  in  preparing  the 
artwork.  This  lets  someone  who  is  reviewing  the  drawing  package 
for  the  next  procurement  look  at  those  notes  and  determine  if  his 
processing  tolerances  are  adequate  to  build  that  board. 

To  determine  such  allowances,  there's  a  table  in  the  new  -275  that 
say  if  you  are  building  a  panel  that  is  less  than  12  inches,  you 
should  add  (if  you're  building  what  they  call  a  "preferred  cate¬ 
gory  board”)  .028  inch  manufacturing  allowance  to  a  drilled  hole. 
If  you're  building  what  they  call  a  "standard  board",  you  add  .020 
inch  and,  for  "reduced  producibility  boards",  add  .012  inch.  Then 
there  is  a  formula  to  determine  if  you  have  the  right  land  size, 
but  you  must  also  consider  etching  or  any  other  problems.  Another 
subtlety  in  getting  to  the  required  -55110  annular  ring  is  that 
for  two-sided  boards,  the  annular  ring  is  measured  from  the  plated 
hole,  but  for  multilayer  boards,  it  is  measured  from  the  drilled 
hole.  So  you  get  some  additional  advantage  in  the  two-sided 
boards  as  far  as  making  the  land  as  small  as  possible.  I  high¬ 
light  these  thing  for  you  only  because  they  must  be  considered  by 
the  designer. 

Mr.  Taylor  mentioned  that  there  is  an  IPC  specification  on  auto¬ 
mated  language  for  printed  wiring  that  has  been  called  out  in 
DOD-STD-100C .  It  is  mandatory  in  -275,  that  if  you  supply  a 
magnetic  tape  of  the  computer  program  to  the  Government,  that  the 
language  used  to  define  the  board  or  artwork  be  in  accordance  with 
IPC-D-350.  That  document  was  developed  by  an  IPC  committee,  coor¬ 
dinated  with  ANSI,  and  approved  for  use  by  the  Department  of 
Defense.  This  is  another  example  of  where  the  Government  is 
starting  to  use  industry  documents. 

Another  item  of  interest  is  that  although  we  have  talked  about 
datums  in  the  old  -275,  this  time  the  requirements  are  a  little 
more  specific.  You  will  have  two  datums  on  your  board;  however 
you  need  have  only  two  holes  to  define  these  datums.  (The  old 
standard  required  three  basic  holes.) 


In  paragraph  4.4  of  the  document  there's  the  statement  that  talks 
about  the  assembly  drawing.  Now,  people  will  say,  "Why  are  you 
talking  about  an  assembly  drawing  in  a  design  document?",  but  most 
of  you  know  that  the  procurement  package  is  made  from  the  design 
layout.  The  group  that  met  determined  there  are  certain  problems 
created  downstream  because  things  are  not  documented  properly,  so 
in  the  new  -275  you  will  find  a  statement  that  says  assembly  docu¬ 
mentation  shall,  as  a  minimum,  call  out  things  like: 

o  Lead  forming  (something  we  never  called  out  before). 

o  Cleanliness  requirements.  (It  is  of  great  concern  that  the 
boards  be  clean  prior  to  putting  conformal  coating  or 
sodium  mask  on  the  board  because  of  reversion  of  the  mater¬ 
ial  due  to  contamination  under  the  various  coatings. 

o  Location  and  identification  of  components.  (We've  always 
had  component  orientation  and  polarity). 

o  Structuring  detail  should  also  be  documented. 


o  Electrical  testing  requirements,  if  any. 

Then  there  is  a  subtle  little  note  that  says  all  appropriate 
assembly  requirements  in  Section  6  shall  be  defined.  Section  6 
has  paragraph  after  paragraph  of  assembly  information  detailing 
mounting  requirements. 

The  group  tried  to  ensure  that  when  a  documentation  package  is 
developed,  the  next  user  doesn't  have  sixteen  thousand  questions 
on  what's  required  or  product  scrap  in  the  process. 

Section  5  deals  with  the  board  requirements.  The  conductor  thick¬ 
ness  and  width  are  very  similar  to  what  they  were  in  prior  issues. 
They  still  are  based  on  the  current  carrying  requirements.  How¬ 
ever,  we  are  allowed  to  go  down  to  5  mil  spacing  on  the  end  pro¬ 
duct  board,  which  is  new.  We  convinced  ourselves  that  this  was  a 
good  thing  to  do  because  multi-layer  boards  were  already  allowed 
to  go  down  to  five  mil  spacing  on  internal  layers.  Since  we  are 
talking  about  conformally-coated  boards,  there  is  no  need  to  worry 
about  the  electrical  clearance. 

There's  another  statement  in  there  which  may  get  some  of  you  in 
trouble.  It  says  that  the  minimum  conductor  width  specified  on 
the  master  drawings  shall  not  be  less  than  eight  mils  wide.  Now 
that's  the  end  product  minimum.  You  can  still  have  nicks  and 
dents  per  -55110,  but  I  caution  all  of  you  that  your  designers 
must  not  suddenly  start  designing  boards  where  you  are  attempting 
to  put  .008  inch  conductors  on  the  artwork  without  manufacturing 
allowances.  The  intent  here  was  that  people  had  been  making  art¬ 
work  with  ten  mils,  then  you've  reduced  the  line  by  a  couple  of 
thousands  and  wound  up  with  eight  mils.  These  boards  have  func¬ 
tioned  adequately.  They've  had  no  problem.  So  we've  convinced 


ourselves  that  eight  mils  was  a  good  number  to  put  on  the  master 
drawing  as  a  minimum.  Don't  misinterpret  that  this  is  equal  to 
the  old  .010  inch  minimum  that  used  to  be  there.  People  misuse 
that  kind  of  concept. 

Comments  on  interfacial  connections  are  still  there.  Eyelets, 
rivets,  pins,  etc,  shall  not  be  used  as  interfacial  connections. 
Clinch  wires  are  still  good  as  an  interfacial  connection;  however 
they're  part  of  the  assembly  and  should  not  be  considered  as  part 
of  the  board.  If  you  are  doing  electrical  continuity  tests,  this 
may  give  you  a  bit  of  a  problem.  In  the  paragraphs  on  interfacial 
connections,  there  is  an  important  statement  on  solder  plugs. 
Solder  plugs  have  been  a  very  emotional  thing  with  our  industry 
and  the  Services  as  to  whether  the  plug  is  good  or  whether  it's 
bad,  whether  the  board  is  more  reliable  with  the  plug  in  the 
plated  holes  or  without  it.  Many,  many  hours  and  many  arguments 
have  taken  place  on  that  particular  subject. 

We  had  one  coordination  meeting  during  which  one  individual  stated 
that  he  had  data  proving  beyond  a  shadow  of  a  doubt  that  a  hole 
without  solder  was  more  reliable  than  the  hole  with  solder.  A 
gentlemen  from  the  Navy  stood  up  and  said,  "O.K.,  keep  all  the 
solder  out  of  the  holes."  Well,  we  don't  want  that  either.  What 
we  want  is  to  stop  degrading  the  board  at  the  assembly  level  by 
going  back  and  touching  up  those  holes  that  didn't  fill  with  a 
soldering  iron--that  was  the  whole  concern. 

We  had  many  discussions  where  people  would  say,  "What  if  I'm  build 
ing  boards  with  flat  packs  on  them?  I  have  a  lot  of  live  holes; 
what  do  I  do  to  fill  those  up?  Do  I  have  to  go  back  and  solder 
them?"  We  all  agree  the  minute  you  put  a  soldering  iron  to  the 
board  you  have  the  potential  of  degrading  it  a  little  further.  So 
there's  now  a  new  statement  in  -275  that  tries  to  give  us  a  little 
edge  on  soldering.  First  of  all,  we  said  solder  plugs  are  requir¬ 
ed  every  place  there's  a  lead  and  the  lead  and  the  hole  are  elec¬ 
trically  functional.  That  is  understandable — you've  got  to  con¬ 
nect  the  two.  A  plated  thru  hole,  whether  it's  functional  or  not, 
whether  it's  got  a  lead  or  not,  the  minute  it  sees  a  solder  wave 
it  should  be  plugged,  too.  Now,  the  concern  there  is  what  if  you 
don't  plug  all  the  holes?  We  hope  to  resolve  that  when  we  get  to 
MIL-P-28809,  which  is  currently  being  worked  on  to  give  some 
relief  (e.g.,  if  out  of  2000  holes,  three  don't  plug,  it's  not  a 
concern--you  don't  throw  the  boards  away). 

During  these  emotional  discussions  we  finally  got  to  the  root  of 
the  problem.  It  isn't  so  much  that  the  customer  wants  the  solder 
plug;  the  lack  of  solder  is  an  indicator  to  him  that  there's  some¬ 
thing  wrong.  When  boards  pass  across  the  solder  wave,  the  holes 
should  naturally  plug  due  to  capillary  action  and  the  laws  of 
physics.  So  we  made  a  compromise.  We  said,  "Suppose  the  boards 
that  don't  see  the  solder  wave  don’t  have  a  plug.  Is  that  all 
right?"  And  they  said,  "Yes,  if  we  have  some  assurances  that  the 


copper  is  good."  We,  therefore,  added  a  requirement  in  MIL-D- 
55110  that  a  coupon  be  solder  shot  for  two-sided  boards  and  micro- 
sectioned  to  give  assurance  that  those  two-sided  panels  were 
really  good.  We  hope  that  this  will  be  of  benefit  to  user  and 
vendor  alike.  We  don't  have  to  go  back  and  touch  up  all  these 
separate  holes  with  a  soldering  iron. 

I  don't  know  how  many  of  you  have  been  involved  in  the  discussions 
regarding  whether  one  should  remove  nonfunctional  lands  or  not  in 
multilayer  boards.  We've  been  involved  with  it  at  IPC.  We  have 
as  many  different  opinions  on  that  as  we  have  members.  I've 
talked  to  people  who  can  build  boards  with  them.  I've  talked  to 
people  who  can  build  boards  without  them.  I  think  it's  an  emo¬ 
tional  preference. 

The  truth  of  the  matter,  in  my  opinion,  is  that  the  only  time  it 
becomes  a  problem  is  when  there  are  a  very  large  number  of  layers 
and  the  dielectric  separation  is  very  thin.  Then  those  posts 
start  to  give  you  a  problem.  Other  than  that,  it's  a  preference 
thing.  Yes,  people  said,  "Gee,  you've  got  to  inspect  more."  On 
the  other  side  of  the  coin,  there  are  people  who  say  they  want  to 
leave  them  in  because  the  drill  is  cooler  as  it  is  going  through; 
you  have  less  epoxy  smear. 

After  many  hours  of  debate,  the  new  -275  says  that  nonfunctional 
lands  are  required  except  on  ground  planes.  There  is  also  a  note 
which  waives  this  requirement  where  electrical  clearances  dictate 
that  you  can't  have  them.  Now,  you  know,  that  leaves  it  up  for 
grabs. 

There  is  a  statement  in  the  new  standard  that  says  the  minimum 
laminate  thinness  permitted  is  .002  inch.  Don't  be  mislead  by 
that — in  another  paragraph  it  says  that  the  dielectric  separations 
between  two  conductive  surfaces  shall  be  no  less  than  .0035  inch. 
The  reason  that  .002  inch  minimum  was  permitted  is  some  people 
said  that  they  used  single-sided  thin  laminate  in  such  a  way  (bond¬ 
ing  it)  that  the  dielectric  separation  is  met,  but  they  like  to 
use  two  mil  thin  laminates.  Don't  let  your  designers  design  you 
in  a  pocket  where  you  find  that  the  dialectic  separation  on  a 
multilayer  board  is  less  than  .0035  inch. 

Another  benefit  for  industry  was  that  we  finally  agreed  to  allow 
the  use  of  1-ounce  copper  on  the  internal  layer  of  multilayer 
boards.  Even  that's  not  real  clean.  The  first  buried  layer 
coming  in  from  either  outside  layer  must  be  2-ounce.  The  dis¬ 
cussions  and  the  theory  behind  that  says  that  the  2-ounce  has  a 
better  locking  action  for  plated  thru  holes  and,  therefore,  will 
give  you  a  better  guard  against  the  thermal  expansion  character¬ 
istics  of  the  epoxy  and  improved  plating  in  the  holes. 
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Documentation  for  printed  boards  should  not  call  out  the  kind  of 
cladding  that  is  used.  Now,  drawings  that  I've  seen  have  always 
specified  the  exact  material  callout  per  MIL-P-13949.  The  call¬ 
outs  define  the  copper  cladding  on  each  side  of  the  laminate. 

This  doesn't  give  your  vendor  enough  leeway.  The  new  -275  allows 
for  the  use  of  half-ounce  copper  on  the  surface.  This  can  give 
you  a  finer  line  definition.  My  recommendation  is  to  specify  only 
the  final  copper  thickness  requirements;  leave  the  copper  foil  at 
the  option  of  the  vendor.  Whether  he  starts  with  half-ounce, 
1-ounce,  or  2-ounce,  is  really  up  to  him  as  long  as  you  get  the 
required  copper  in  the  plated  thru  holes  and  on  the  surface. 

We  still  have  the  need  for  tin-lead  plating  and  coatings  and  we 
still  have  two-part  connectors.  No  card  edge  connectors  are 
allowed  in  -275. 

Section  6  talks  about  part  mounting,  greater  stress  on  cleanli¬ 
ness,  as  I  said  before.  If  approved,  you're  allowed  to  have  sur¬ 
face  lead  mounting.  Of  course,  flat  packs  are  surface  mounted, 
but  the  theory  is  that  if  everything  is  surface  mounted  (for 
example,  even  resistor  leads  are  flattened),  you  need  approval. 
Perpendicular  mounting,  when  specified,  is  permissible. 

We  talked  about  the  compatibility  of  conformal  coating  and  the 
solder  mask.  A  buffer  material  is  still  required  when  those  parts 
that  are  very  brittle  are  coated  with  the  conformal  coating. 

There  is  an  appendix  in  MIL-STD-275  that  gives  you  a  lot  of  good 
design  information.  It  has  hole-to-land  ratios,  conductor  spac¬ 
ing,  feature  location  accuracies,  master  pattern  material  move¬ 
ment,  registration,  etc.  This  table  is  an  update  of  the  original 
MIL-STD-55640  design  requirement  table.  It's  in  the  appendix  as 
a  guide  only.  However,  if  you  took  all  those  numbers  and  worked 
them  out  in  an  equation  to  calculate  your  minimum  land  requirement 
for  a  particular  hole,  you  would  find  they  approximate  the  numbers 
that  are  in  the  body  of  the  specification.  These  numbers  were 
developed  by  statistical  survey;  asking  people  what  they  used. 
Basically,  that's  MIL-STD-275D. 

MIL-P-55110  has  not  had  too  many  major  changes;  still  it  had 
single,  double,  and  multilayer  boards  incorporated.  I  guess  the 
real  changes  are  in  the  testing  that  you  perform  during  board 
manufacture.  (There  are  frequent  in-process  cleanliness  tests 
required.)  The  Group  A  Inspection  is  a  sampling  plan  inspection 
with  most  of  the  requirements  for  visual  layers  registration, 
plating  thickness,  adhesions,  solder abil ity ,  warp,  stress,  and 
that  kind  of  thing.  On  multilayer  boards,  there  is  a  requirement 
that  one  coupon  per  panel  be  thermally  stressed  and  microsec- 
tioned.  I  think  that  all  members  of  the  group  wanted  assurance 
that  processing  variances  did  not  adversely  affect  a  multilayer 
panel.  They  felt  that  a  look  at  the  copper,  hole,  and  regis¬ 
tration  of  each  panel  is  essential.  Everyone  is  very  concerned 
that  the  location  of  the  coupon  be  representative  of  the  panel. 
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There  is  still  a  Group  B  Inspection,  but  no  Group  C.  (This  is 
different  from  -55110B).  Group  B  is  performed  once  a  month  on  two 
of  the  most  complex  boards  of  a  particular  type.  It  includes 
cleanliness,  bond  strength,  interconnection,  resistance,  moisture 
and  insulation  resistance,  and  dielectric  ability  to  withstand 
voltage.  The  moisutre  exposure  will  take  quite  a  bit  of  time. 

The  testing  to  get  the  product  from  the  manufacturer  into  your 
hands  or  into  the  Government's  hands  has  really  been  streamlined 
quite  a  bit.  We  are  confident  that  what  we  are  doing  is  going  to 
be  representative  of  a  particular  product. 

One  of  the  biggest  concerns,  however,  in  our  industry — most  contro- 
vesial — is  the  requirement  that  to  build  boards  to  MIL-P-55110, 
you  must  be  a  certified  manufacturer.  Let  me  tell  you  how  we  got 
into  that  situation.  The  previous  -55110  required  that  when  you 
got  a  contract  to  build  boards  for  the  Government,  before  you 
could  start  production,  you  had  to  build  what  was  called  a  prepro¬ 
duction  sample.  What  you  did  was:  (1)  if  you  had  a  contract  that 
had  thirty  board  types  you  first  argued  with  your  DCASR  as  to 
which  was  the  most  complex  type,  (2)  once  you  decided  that,  you 
built  six  boards,  and  (3)  tested  those  six  boards  to  all  of  the 
requirements  for  preproduction  testing.  If  they  passed,  you  had 
permission  to  start  production.  The  only  problem  was  that  if  you 
were  building  a  two-sided  board,  testing  sometimes  lasted  four 
weeks.  So  you  didn't  start,  although  you  really  did,  and  you  took 
a  risk.  For  multilayer  boards,  it  took  a  little  longer. 

The  other  thing  that  seemed  unfair  about  it — a  waste  of  taxpayer 
dollars — was  the  fact  that  if  you  had  a  contract  for  the  Army  this 
week  and  one  for  the  Navy  next  week,  you  built  another  six  boards. 
So  we  sat  down  and  asked  ourselves  "Isn't  there  a  better  way  to  do 
this?"  The  Services  asked  IPC  if  we  had  any  kind  of  a  standard 
specimen  that  is  representative  of  the  state-of-the-art  of  what  is 
being  built.  It  just  so  happened  we  had  the  B-25  Test  Board.  It 
was  developed  by  a  committeeto  do  some  insulation  resistance 
testing. 

Let  me  take  a  few  minutes  to  describe  the  test  boards.  The  B-25 
multipurpose  testboard  is  attached.  The  board  is  about  4x5  in¬ 
ches.  It  does  have  a  card-edge  connector  even  though  the  military 
specifications  don't  allow  it.  The  reason  is  that  we  hope  to  use 
it  to  facilitate  testing.  There  are  the  three  comb  patterns. 

Each  of  these  comb  patterns  has  a  different  comb  size.  Comb  pat¬ 
tern  "A"  has  a  6-1/2  mil  line  and  a  6-1/2  mil  space.  Comb  pattern 
"B"  has  a  12-1/2  mile  line  and  a  12-1/2  mil  space,  and  comb  pat¬ 
tern  "C"  has  a  25  mil  line  and  a  25  mil  space.  The  one  that  is 
required  to  do  certification  testing  is  pattern  "B"  with  the 
12-1/2  lines  and  spaces.  The  Services  felt  that  the  way  the 
state-of-the-art  is  at  the  moment  this  pattern  would  be  the  best 
basis  for  doing  the  insulation,  resistance,  after  moisture,  the 
dielectric  withstanding  voltage,  and  other  tests.  One  important 
thing  is  that  the  boards  that  are  tested  ought  to  be  conformally 
coated.  Some  people  are  finding  that  they  can't  pass  these  tests 


after  moisture  using  uncoated  boards,  even  though  the  final  mea¬ 
surements  are  made  two  hours  after  they  come  out  of  the  moisture 
chamber.  The  comb  patterns  are  part  of  these  tests. 

There's  a  pattern  "L"  and  a  pattern  "J" .  Pattern  "J"  is  repeated 
on  the  other  side  of  the  board;  both  of  these  patterns  are  used 
for  inter  laminate  dielectric  tests.  In  other  words,  they're  check 
ing  the  dielectric  separation  between  the  holes.  These  holes  are 
on  100-mil  spacing.  Pattern  "L"  is  used  for  terminal  pull  and 
there  is  a  similar  pattern  to  "L"  on  the  other  side  of  the  board, 
which  is  pattern  "K".  That's  a  non-plated  thru  hole  used  for  the 
terminal  pull. 

Pattern  "R"  is  used  for  conductivity  testing  after  thermal  shock 
cycling,  100  cycles  from  -65^  to  the  highest  temperature  limit 
for  the  material,  then  you  check  the  copper.  There  are  also  pat¬ 
terns  for  peal  strenght  and  solder-mask  over  bare  metal. 

After  all  these  months  I  got  a  call  just  the  other  day  from  some¬ 
body  at  Sandia  Laboratories.  He  said,  "You  know,  you  say  in  your 
document  -55110  ..."  (I  don't  know  why  he  says  it's  m^  document). 
He  says  that  the  specification  requires  that  the  copper  resistance 
be  no  greater  than  one  milliohm  per  .125  inch  of  conductor.  Fur¬ 
ther,  he  says  that  due  to  the  laws  of  physics  of  copper,  there 
isn't  enough  copper,  and  lo  and  behold,  it  turns  out  that  every 
place  else  in  the  coupons  we  have  a  70-mil  conductor  except  on 
this  particular  pattern.  So  if  any  of  you  are  doing  certification 
testing  and  are  not  passing  that  test,  it's  becuase  you  can't.  We 
are  going  to  try  to  straighten  this  out  by  putting  a  note  under 
the  table  saying  that  when  you  are  using  the  B-25  board,  you  can 
have  other  number  resistance. 

The  B-27  boards  provide  test  patterns  for  circuit  continuity  test, 
plating  and  minimum  pull  test,  dielectric  strength  between  layers, 
plated  thru  hole  structure  test,  etc.  We  had  not  defined  the 
requirements  for  these  boards  too  well.  What  has  happened  is  that 
DESC  has  asked  us  to  make  a  master  drawing  for  the  B-25  and  the 
B-27  boards.  This  is  now  also  being  circulated  and  probably  some¬ 
time  toward  the  end  of  the  year  after  all  industry  and  the  Ser¬ 
vices  agree,  you  will  have  some  very  definite  requirements  on  how 
these  boards  must  be  made. 

In  the  multilayer  boards,  you  are  going  to  have  to  build  a  board 
that  has  a  four  mil  core,  eight  mil  core,  eight,  eight  and  then 
four  with  twelve  mil  prepreg,  eight,  eight,  and  twelve  to  give  you 
a  total  that's  somewhere  between  80  and  100  mils.  The  toler¬ 
ances  on  each  of  these  is  plus  or  minus  two  mils  and  then  the 
overall  master  drawing  requirements.  We  are  putting  all  the  tol¬ 
erance  on  the  drawings.  If  you  have  any  comments  on  the  attached 
master  drawings  of  B-25  and  B-27  send  them  to  me. 


That's  about  where  we  are  with  the  requirements  of  -275  and 
-55110.  Sometime  this  summer  we'll  have  a  coordination  meeting  on 
the  master  drawings  and  the  certification  requirements,  if  we  in 
industry  are  to  take  that  over.  There  is  still  the  problem  of 
measles  to  be  solved  and  MIL-P-28809.  We  are  working  diligently 
with  the  Services  on  these  problems. 

Thank  you  very  much  for  your  time  and  attention. 
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It's  a  pleasure  for  me  to  be  here  today  and  to  have  an  opportunity 
to  tell  you  about  the  DoD  Parts  Control  Program.  I  will  tell  you 
something  about  what  we  do  and  what  the  Military  Parts  Control 
Advisory  Group  (MIPCAG)  is.  The  acronym  MPCAG  (pronounced  "mip- 
cag")  will  be  referred  to  quite  a  few  times  during  this  short 
briefing.  I'll  give  you  an  overview,  some  background  on  where  the 
program  came  from,  how  it  works,  what  we  do,  some  of  the  benefits, 
and  how  it  has  grown. 

There  are  three  basic  objectives  of  a  Parts  Control  Program  (Fig¬ 
ure  1):  (1)  minimize  the  variety  of  parts  that  are  being  designed 

into  new  equipment  and  thus  also  minimize  the  variety  of  nonstan¬ 
dard  parts  that  are  entering  the  DoD  Logistic  inventory,  (2) 
enhance  and  maintain  the  reliability  of  the  Systems  by  maximizing 
the  use  of  standa.rd  parts  while  minimizing  the  different  varieties 
of  parts,  and  (3)  keep  the  military  specifications  and  standards 
current — we  simply  must  have  current  specifications  if  we  are 
going  to  recommend  standard  parts. 

Every  study  and  report  that  we  reviewed,  dating  back  several 
years,  has  a  common  thread;  that  is,  if  you  are  going  to  be  suc¬ 
cessful  in  standardization,  you  must  do  it  while  the  equipment  is 
being  designed  (Figure  2).  If  you  wait  until  the  equipment  is  in 
the  Government  inventory  to  try  to  standardize  the  parts,  it's 
simply  too  late. 

In  1969,  a  DoD  Task  Group  tried  to  determine  if  a  centralized 
group  of  engineers  and  technicians  could  be  effective  in  trying  to 
promote  standardization  during  design.  They  determined  that  per¬ 
haps  a  study  project  should  be  conducted  to  see  if  standardization 
would  work  and  if  a  group  of  parts  experts  could  improve  the  stan¬ 
dardization  during  the  design  phase  working  with  military  pro¬ 
curing  activities  and  their  contractors.  They  initiateda  study 
project  and  named  the  Defense  Electronics  Supplies  Centers  Engi¬ 
neering  Directorate  (DESC-E)  to  conduct  the  study.  This  wasn't 
really  an  accidental  selection  because  we  had  a  couple  of  things 
going  for  us  at  the  time.  We  had  fully  one  fourth  of  all  the  new 
stock  numbers  that  were  being  assigned  to  the  federal  supply 
classes.  Thus  we  had  a  proliferation  problem  in  electronic  parts. 
Many  nonstandard  parts  were  being  entered  into  the  inventory  each 
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year.  Vie  also  had  a  group  of  parts  experts  that  had  been  prepar¬ 
ing  military  specifications  and  standards  on  resistors,  capaci¬ 
tors,  and  other  various  electronic  components  for  many  years  as 
agent  for  the  various  military  departments.  We  had  those  two 
things  going  for  us  and  we  determined  how  to  conduct  a  feasibility 
study  and  embarked  upon  it,  supporting  Air  Force  contracts  primari 
ly,  plus  one  or  two  Army,  and  one  Navy  contract. 

Even  before  the  study  was  completed  and  a  final  report  prepared, 
it  was  determined  that  it  was  a  very  cost  effective  program.  In 
1972,  DESC-E  became  the  first  Military  Parts  Control  Advisory 
Group  designated  to  support  military  contracts.  They  were  asked 
by  the  procuring  activity  to  help  in  the  selection  of  standard 
parts  during  the  design  phase.  The  program  continued  to  grow  and, 
in  1975,  the  JL  Report  indicated  that  this  was  a  good  program, 
should  be  DoD-wide,  and  further  that  there  should  be  a  DoD  policy 
generated  for  the  program.  So  the  DoD  Task  Group  was  reactivated 
under  Mr.  Mitchell's  chairmanship.  They  developed  DoD  policy 
documents  for  the  Parts  Control  Program  in  the  form  of  DoD  Instruc 
tion  4120.19  in  December  1976  (Figure  3).  This  was  followed  by 
implementing  instructions  and  regulations  by  the  Military  Depart¬ 
ment  and  Defense  Logistics  Agency  (DLA). 

In  1977,  MIL-STD-965  which  is  the  contract  implementing  document 
along  with  the  data  items  required  for  implementing  the  program 
were  all  completed;  we  had  a  full-fledged  DoD  Parts  Control  Pro¬ 
gram. 

Now  the  responsibility  for  implementing  the  program  lies  both  with 
the  Military  and  DLA  (Figure  4).  The  Military  must  first  contrac¬ 
tually  implement  the  program  by  applying  the  data  item — a  volun¬ 
tary  effort  simply  is  not  successful.  Of  course,  the  Military 
also  retains  the  authority  and  responsibility  for  final  approval 
of  whatever  is  used  in  their  equipment;  they  have  the  authority 
and  the  right  to  say  what  parts  are  going  to  be  used. 

What  the  MPCAG  does  is  to  provide  a  technical  expert  sitting  at 
the  design  activity's  right  hand  to  make  recommendations.  DLA, 
for  its  part,  agreed  to  take  the  responsibility  to  establish 
additional  MPCAG's  at  other  centers  where  they  had  parts  experts 
working  in  other  areas — mechanical  parts,  electrical  parts,  etc. 
These  MPCAGs  would  provide  part  selection  expertise  to  the  Mili¬ 
tary  Departments,  create  an  automated  data  processing  system  that 
would  provide  for  rapid  storage  and  retrieval  of  nonstandard  parts 
data.  They  not  only  determine  the  standardization  needs,  but  do 
something  about  it.  In  other  words,  they  would  change  the  specifi 
cations  and  standards  to  keep  them  in  a  current  condition,  adding 
those  parts  that  needed  to  be  added. 

Figure  5  lists  the  various  MIPCAG  areas  of  responsibility.  In 
1972,  DLA  created  the  DESC-E  MPCAG  covering  the  items  listed.  In 
1975,  they  created  another  MPCAG,  a  mechanical  part  MPCAG  at  the 
Defense  Industrial  Supply  Center  in  Philadelphia,  covering  bear¬ 
ings,  fasteners,  and  mechanical  parts  of  this  type.  Then  in  1978, 
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two  additional  MPCAGs  at  Defense  General  Supply  at  Richmond  and 
another  Defense  and  Construction  Supply  in  Columbus,  Ohio,  were 
created  to  cover  the  entire  gamut  of  electrical,  electronic  and 
mechanical  parts  the  military  feels  need  to  be  controlled  during 
new  design  efforts.  In  conducting  this  program,  we  work  with 
virtually  everybody  that  is  interested  in  using  parts,  manufactur¬ 
ing  parts,  etc.  The  various  military  departments  and  the  major 
commands  within  those  departments  have  engineers  that  interface 
with  the  major  industry  associations,  as  well  as  the  various  OEMs 
and  contractors  with  whom  we  interface  on  a  daily  basis  in  trying 
to  help  them  with  the  selection  of  standard  parts  for  new  designs. 

Figure  6  depicts  the  basic  interface  that  occurs  and  how  the  on¬ 
going  program  works.  It  shows  MPCAG  supporting  the  military  pro¬ 
curing  activity  and  the  contractor.  Figure  7  shows  a  lot  of  com¬ 
munication  with  the  contractor,  not  only  in  writing  but  by  phone. 
Our  engineers  talk  to  the  designer  and  contractor  about  part 
problems,  and  if  he  is  requesting  the  use  of  a  nonstandard  part, 
he  can  do  so  by  phone.  We  will  document  that  request,  make  a 
recommendation  on  it,  and  forward  it  to  the  procuring  activity. 

In  this  way,  the  procuring  activity  knows  what  has  been  talked 
about  and  what  we  recommend.  Through  telephone  requests, the  cost 
of  paperwork  is  reduced;  therefore  the  overall  cost  of  the  con¬ 
tract  should  be  reduced. 

We  not  only  review  parts  over  the  phone,  but  list  the  proposed 
parts  he  intends  to  use  in  design.  If  a  nonstandard  part  is 
approved  and  he  covers  it  with  a  drawing,  we  review  the  drawing 
and  offer  recommendations  as  to  its  adequacy  for  follow-on  procure¬ 
ment  by  the  Military  when  it  becomes  Government  property.  In 
addition,  we  provide  expedited  military  specification  service  for 
those  items  that  need  to  be  covered  by  military  specification.  We 
have  put  out  military  specifications  in  as  little  time  as  two 
weeks.  QPL  information  is  provided  to  the  procuring  activity  and 
the  contractor  during  the  design  phase  of  a  piece  of  equipment  or 
gear.  So  our  main  purpose  (Figure  8)  really  is  to  make  recom¬ 
mendations  quickly  (we  emphasize  the  term  "recommendations")  to 
the  equipment  designers  acting  as  the  technical  experts  for  the 
procuring  activity. 

Now  you  say,  "So  what?  Why  are  you  so  worried  about  nonstandard 
parts  getting  into  the  system?"  Well,  there  are  a  lot  of  things 
that  happen  when  nonstandard  parts  enter  the  system  and  they  are 
all  pretty  costly  (Figure  9).  In  the  acquisition  phase,  each 
nonstandard  part  that's  approved  usually  requires  some  documenta¬ 
tion  in  the  form  of  a  specification  or  source  control  drawing  or 
other  document.  These  documents  cost  the  Government  lots  of 
money.  We've  had  data  that  indicated  they  range  from  $500  up  to 
$8000  in  cost.  We're  talking  about  the  cost  of  verification 
testing  of  a  nonstandard  part  that's  been  approved  by  the  OEM  to 
determine  that  it  meets  the  requirements  of  the  system  contract. 
These  tests  can  cost  as  much  as  $25,000.  We've  seen  invoices 
reflecting  these  costs  for  some  of  the  more  complex  microcircuits 
that  have  been  thoroughly  tested. 
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Those  costs  are  in  the  acquisition  phase.  On  the  logistics  side, 
of  course,  every  new  stock  number  that's  assigned  costs  administra 
tive  money.  To  support  what  we  are  using  right  now  at  DESC  is 
$270  administrative  cost  for  every  Federal  Stock  Number  (nonstan¬ 
dard  number)  that  is  developed.  If  you  go  further  and  talk  about 
maintaining  the  nonstandard  number  over  a  10-year  life  of  the 
equipment,  you're  looking  at  another  $1600.  On  top  of  that,  if 
you  add  the  fact  that  the  nonstandard  part  will  tend  to  fail  more 
often  than  the  standard  part,  and  apply  some  very  conservative 
figures  of  say  $300  for  each  maintainance  action,  over  a  10-year 
life  you're  talking  about  at  least  $3000  for  each  nonstandard 
part.  These  are  the  types  of  costs  that  are  incurred  by  nonstan¬ 
dard  parts  and  the  costs  we  are  trying  to  avoid.  Significant 
savings  can  be  realized.  That's  what  our  benefit  to  the  equip¬ 
ment,  to  the  system,  and  to  the  logistic  system  is  based  on. 

Let  me  take  a  moment  to  give  you  an  example  of  what  I'm  talking 
about  (Figure  10).  We  were  seeing  a  lot  of  operational  amplifier 
microcircuits  and  we  tried  to  develop  a  trend  to  see  what  types 
were  actually  being  used.  We  discovered  that  about  four  basic 
part  types  and  about  twenty  different  part  numbers  covered  most  of 
the  requirements.  We  had  50  and  60  nonstandard  parts  come  in 
requesting  approval.  We  didn't  have  a  standard  to  recommend  in 
their  place.  So  we  took  the  four  part  types  and  twenty  part 
numbers  and  put  them  in  a  slash  sheet  to  MIL-M-38510  ( /I 0 1 )  and 
applied  them  on  all  new  nonstandard  parts  where  these  parts  would 
do  the  job.  We  recommended  /101  parts  and,  in  fact,  they  was 
used . 

If  you  apply  the  mathematics  to  the  costs  of  the  testing  that  was 
avoided,  the  drawings  avoided,  and  the  logistic  savings;  the  first 
year  alone  we  were  looking  at  $500,000  worth  of  cost  avoidance. 
That's  not  out-of-pocket  savings,  it's  what  we  would  have  spent  if 
we  had  not  been  involved  in  the  program.  We  looked  at  that  recent 
ly  to  see  if  we  really  had  accomplished  what  we  thought  we  accomp¬ 
lished  with  that  one  basic  standardization  action.  We  reviewed 
material  back  to  1973  (Figure  11).  We  had  recommended  that  slash 
sheet  (/101)  items  491  times  on  125  contracts.  If  you  apply  the 
conservative  mathemathics  to  that  figure,  you're  looking  at  6 
million  dollars  worth  of  savings.  Of  course,  it's  not  free — we 
had  to  create  and  maintain  the  specification,  but  for  $61,000  cost 
for  that  we  have  a  103-to-l  benef it-to-cost  ratio.  For  every 
dollar  we  spent  we  avoided  $103  in  expenditure. 

Figure  12  illustrates  the  breakdown  of  the  contracts,  by  percent¬ 
age,  that  we  work  on  today.  Still,  almost  half  of  them  are  Air 
Force  contracts.  The  Air  Force  saw  the  need  for  a  centralized 
activity  as  far  back  as  1967  and  we  have  been  working  with  them 
for  many  years.  The  Army  and  Navy  have  been  increasing  the  number 
of  contracts  that  we  work  on  for  some  time  now  and  they  are  improv 
ing  as  far  as  quantity  is  concerned  but  their  percentage,  of 
course,  stays  pretty  much  the  same. 


Just  a  quick  word  about  MIL-STD-965  that  I  mentioned  earlier 
(Figure  13):  it  replaces  some  documentation  that  you  may  be  aware 
of  including  MIL-STD-749,  the  old  submittal  of  non-standard  parts 
document.  It's  a  DoD  Program  and  MIL-STD-965  was  written  by  the 
DoD  Task  Group,  as  I  mentioned.  Figure  14  shows  how  the  program 
has  grown.  Contracts  supported  by  us  in  1973,  when  the  DECS  MPCAG 
was  very  young,  totaled  57  contracts.  It's  grown  every  year  to 
the  396  supported  in  1978.  To  date,  we  have  worked  on  over  450 
contracts  and  this  includes  projects  like  F-16,  F-18,  small  black 
boxes,  small  pieces  of  equipment,  modification  contracts,  almost 
all  the  major  weapon  systems  (Figure  15).  We  support  the  military 
procuring  activity  and  their  contractor  or  contractors  on  the 
program. 

The  life  cycle  cost  avoidance  runs  into  the  millions  of  dollars. 
Obviously,  our  costs  (fourth  column  in  Figure  14)  have  gone  up  be¬ 
cause  we  have  many  more  contracts  to  work  on  and  we've  had  to 
acquire  additional  resources.  But  we  are  still  looking  at  an 
83-tol  benef it-to-cost  ratio.  For  every  dollar  we  spend  on  the 
program,  we  avoid  an  $83  expenditure.  That  is  basically  the  Parts 
Control  Program. 

Thank  you  very  much. 
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PARTS  CONTROL  SYSTEM  OBJECTIVES 


•  MINIMIZE  VARIETY  OF  PARTS 

•  ENHANCE  SYSTEM  RELIABILITY  AND  MAINTAINABILITY 

•  KEEP  SPECIFICATIONS  AND  STANDARDS  CURRENT 

Figure  1 
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RESPONSIBILITIES 

MILITARY  DEPARTMENTS 

•  ENSURE  IMPLEMENTATION  IN  CONTRACTS 

•  RETAIN  AUTHORITY/RESPONSIBILITY  FOR  PARTS  SELECTION 

DLA 

•  ESTABLISH  MILITARY  PARTS  CONTROL  ADVISORY  GROUPS  (MPCAGs) 

-  MAINTAIN  BROAD  DATA  BASE  FOR  PARTS 

-  PROVIDE  PARTS  SELECTION  RECOMMENDATIONS  TO  DESIGNERS 

-  USE  AUTOMATION  TO  PROVIDE  RAPID  FLOW,  RETENTION, 
RETRIEVAL  OF  INFORMATION 

-  DETERMINE  STANDARDIZATION  NEEDS 

Figure  4 
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ABSTRACT 

A  job  information  delivery  system  was  designed  to  provide 
AEGIS  with  readiness  assessment  and  fault  analysis  data.  This 
consists  of  the  highly  automated  Operational  Readiness  Test 
System  (ORTS),  supplemented  by  job-relevant  work 
packages  contained  in  an  automatic  retrieval  microfiche  file. 
This  paper  reviews  the  job  information  delivery  system  and 
describes  how  the  concept  of  task-oriented  data  was 
expanded  to  include  management,  supervisory,  and 
operational  positions  within  the  AEGIS  Combat  System. 


THE  USER-ORIENTED  TECHNICAL  MANUALS  FOR  AEGIS 


J.  Fedorko  and  R.  D.  Kemp 


INTRODUCTION 

The  AEGIS  Combat  System  in  DDG  47  is  a  rapid-reaction,  high-firepower  surface  missile 
system  capable  of  dealing  with  the  threats  of  the  1980’s  and  beyond.  The  unprecedented 
quick  reaction  time  and  firepower  of  AEGIS  stem  from  computer-managed  operations 
coupled  with  a  multi-function  phased  array  radar  capable  of  simultaneously  performing  all 
search,  fire  control  quality  tracking,  and  missile  command  midcourse  guidance  functions. 

In  addition  to  being  the  most  advanced  Navy  defensive  weapon  system,  AEGIS  has 
introduced  an  unprecedented  level  of  system  availability.  This  combination  of  capability 
and  availability  is  clearly  a  result  of  careful  preplanning.  A  major  objective  of  the  AEGIS 
design  was  to  produce  a  system  that  provided  continuous  combat  readiness  at  an  acceptable 
level  of  performance.  To  desensitize  system  availability  from  individual  item  malfunctions,  a 
channelized  load-sharing,  redundancy  design  approach  was  established.  In  this  approach,  the 
individual  building  blocks  are  designed  and  interconnected  so  that  multiple  paths 
complement  one  another  in  providing  full  capability,  yet  are  sufficiently  independent  that  a 
malfunction  in  one  path  will  not  restrict  operation  in  the  remaining  paths. 

This  approach  to  system  design  tends  to  de-emphasize  the  urgency  for  immediate 
maintenance,  permitting  deferral  of  many  non-critical  maintenance  actions  until  the  next 
scheduled  maintenance  period,  or  until  cruise  conditions  permit.  Nonetheless,  continuous 
monitoring  of  system  performance  is  required  to  identify  critical  events  that  threaten  to 
bring  the  system  down  or  degrade  the  system  to  an  undesirable  operating  level.  The 
Operational  Readiness  Test  System  MK  1  (ORTS)  provides  on-line  monitoring  of  the 
equipment  and  programs,  automatic  computer  reconfiguration  to  maintain  the  most 
efficient  system,  a  centralized  management  of  all  AEGIS  maintenance  activity,  fault 
detection,  and,  in  many  cases,  fault  isolation  to  the  line  replaceable  unit  (LRU). 

OPERATION  READINESS  TEST  SYSTEM 

The  ORTS  is  a  data  acquisition,  data  processing,  and  display  system  dedicated  to 
continuously  monitoring  the  AEGIS  system  for  the  detection  and  analysis  of  faults. 

ORTS  provides  a  comprehensive  on-line  assessment  of  system  availability,  readiness,  and 
performance  through  a  computer-controlled  operation  that  is  interleaved  with  the  tactical 
program  on  a  non-interference  basis.  The  operator  stationed  at  the  ORTS  console  is 
provided  with  performance  capability  and  fault  analysis  data  consisting  of  fault  location, 
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seriousness  of  fault  (performance  degradation),  and  recommended  steps  of  reactions  to  take 
when  correcting  the  fault.  All  operator  input  instructions  are  initiated  by  keyboard  entry. 
After  replacement  of  the  indicated  faulty  line  replaceable  unit  (LRU),  the  operator  can 
manually  initiate  tests  by  entering  a  specified  code  via  the  keyboard  to  verify  that  the 
corrective  maintenance  eliminated  the  fault. 

In  essence,  ORTS  is  a  job  information  delivery  system  that  automatically  evaluates  the 
entire  system  status,  performs  fault  detection  and  fault  isolation,  and  permits  efficient 
scheduling  of  maintenance  events.  Detailed  procedural  information  for  corrective 
maintenance  is  not  included  in  the  ORTS  message  because  of  limitations  on  available 
computer  memory  and  the  high  cost  of  changing  formatted  messages.  Therefore,  the 
maintenance  procedure  is  replaced  with  a  reference  to  documentation  which  is  contained  in 
a  microfiche  automatic  retrieval  storage  and  display  unit  to  create  a  supplementary  job 
information  delivery  system  for  AEGIS. 

MICROFICHE  FILE 

The  microfiche  automatic  retrieval  storage  and  display  unit  is  a  shipboard  qualified  version 
of  the  commercially  available  unit  manufactured  by  Image  Systems  Inc.  of  Culver  City, 
California  (Figure  1).  One  carrousel  tray  which  holds  780  microfiche  cards  (over  76,000 
frames)  is  contained  within  the  unit  (Figure  2);  cartridges  are  available  to  extend  the 
machine  capability  beyond  this  carrousel  limitation.  Automatic  random  access  card  search 
and  selection  allows  insertion  of  the  cards  in  any  sequence.  Any  microfiche  frame  can  be 
displayed  within  three  seconds  after  insertion  of  a  five-character  code  at  the  keyboard.  A 
hard  copy  printout  can  be  obtained  from  the  dry  process  printer  which  has  been 
incorporated  as  an  integral  part  of  the  unit. 

WORK  PACKAGE  CONCEPT 

All  AEGIS  maintenance  activity  is  planned  and  organized  into  specific  step-by-step 
procedures  for  the  technician  to  follow  in  response  to  a  system  fault  symptom  or  a 
scheduled  maintenance  task.  Test  equipment  and  procedural  guidance  are  readily  and 
conveniently  available  to  him,  even  for  the  faults  most  difficult  to  locate  and  fix.  Figure  3 
depicts  the  AEGIS  maintenance  sequence,  utilizing  a  system-level  work  package  that 
corrects  a  majority  of  the  faults  without  use  of  external  test  equipment  or  more  detailed 
information  than  that  contained  in  the  initial  work  package.  All  ORTS  fault  isolation 
messages  contain  a  reference  to  a  microfiche  work  package  (see  Figure  4).  Equipped  with 
the  work  package  (see  Figure  5),  the  technician  can  draw  the  LRU  to  be  replaced  from  the 
designated  cabinet,  proceed  to  the  equipment,  and  replace  the  faulty  LRU.  Retest  to  ensure 
that  the  replacement  corrected  the  fault  is  accomplished  by  typing  in  a  code  at  the  ORTS 
keyboard.  A  reference  to  a  more  detailed  equipment-level  work  package  is  included,  to  be 
followed  whenever  the  replacement  unit  fails  to  correct  the  fault. 


Equipment-level  woik  packages  are  required  when  either  the  replacement  LRU  fails  to 
correct  the  fault,  ORTS  does  not  fault-isolate  to  the  LRU,  or  when  performance  of 
preventive  maintenance  indicates  a  fault.  These  detailed  work  packages  start  with  the 
observed  fault  and  then  logically  process  through  troubleshooting  steps  that  have  been 
determined  by  maintenance  engineering.  Instructions  for  use  of  portable  test  equipment, 
where  required,  are  included  in  equipment-level  work  packages.  These  work  packages 
provide  the  technician  with  detailed  and  specific  job-related  material  until  the  fault  is 
systematically  corrected.  Reference  diagrams  are  included  with  equipment-level  work 
packages.  These  diagrams  are  uniquely  formatted  for  microfiche  and  are  compatible  with 
hard  copy  requirements.  This  particular  format  was  developed  to  satisfy  comments  on 
microfiche  supplied  by  users  in  the  fleet. 

TASK  ORIENTED  DATA 

The  maintenance  work  package  concept  produced  job  relevant  data  in  only  the  corrective 
maintenance  sections  of  the  technical  manuals.  This  was  unacceptable  to  the  Project 
Manager,  PMS-400,  since  it  did  not  eliminate  the  inherent  problems  of  the  existing 
multi-volume  system  manuals  and  their  multiple  users,  such  as: 

•  enormous  table  of  contents 

•  desired  material  difficult  to  find 

•  material  not  satisfying  different  interests  of  all  readers 

•  material  written  to  incorrect  comprehensibility /reading  levels 

•  superfluous  material 

The  project  manager  directed  that  an  analysis  be  performed  and  other  candidate  areas  for 
task  oriented  data  be  identified.  As  a  result  of  the  analysis,  all  management,  maintenance, 
and  operational  personnel  and  their  responsibilities  were  defined.  Four  organizational  levels 
or  tiers  were  established  in  both  the  maintenance  and  operational  areas,  and  a  new  technical 
manual  hierarchy  was  developed.  The  project  manager  accepted  the  recommendation  that 
task-oriented  material  be  prepared  in  accordance  with  the  hierarchy,  provided  that  the 
material  remained  compatible  with  training  requirements  and  did  not  compromise  any 
configuration  management  doctrine. 

The  technical  manual  hierarchy  for  the  maintenance  area  was  established  to  support  the 
tasks  at  four  levels:  combat  system  test  officer/maintenance  supervisor,  group  supervisors, 
work  center  supervisors,  and  maintainers  (see  Figures  6  and  7).  The  manuals  for  the  top 
three  tiers  of  maintenance  management  address  specific  management  tasks  and  contain 
technical  material  required  for  that  level  of  supervision.  The  information  to  support  the 
maintainer  level  is  divided  into  information  modules  which  agree  with  Naval  Enlisted 
Classification  (NEC)  descriptions  or  with  practical  work  assignments.  Where  applicable,  the 
information  is  in  work  package  format  for  automatic  retrieval  from  the  microfiche  unit. 


A  similar  hierarchy  of  combat  system  operational  manuals  was  developed  to  support  the 
Combat  Information  Center  (CIC)  operational  tasks  at  four  levels:  tactical  command, 
mission  coordination,  system  supervision,  and  system  operation/control  (see  Figure  8).  Each 
person  in  CIC  requires  data  to  describe  the  generalities  of  operation  in  all  warfare  modes, 
console/equipment  descriptions,  specific  principles  of  operation,  and  submode  operating 
procedures.  The  specific  principles  of  operation  must  define  the  duties  of  each  person  in 
CIC,  varying  from  Task  Force  Commanders  to  equipment  level  console  operators.  The  CIC 
multi-purpose  consoles,  under  computer  control,  can  accept  various  submode  assignments. 
These  qualifications  dictate  a  modular  approach  for  generation  and  packaging  of  the 
information  to  maintain  the  same  flexibility  that  was  designed  into  CIC.  The  resulting 
information  modules  or  pamphlets  may  be  gathered  into  a  binder  to  provide  each  position 
or  operator  with  the  task-oriented  data  required  (see  Figure  9). 

To  eliminate  redundancy  of  non-procedural  descriptive  data,  it  was  recommended  that  a 
technical  manual  which  contains  all  system  level  physical  and  functional  description  be 
generated  for  common  use  of  all  combat  system  personnel. 


Figure  1.  Microfiche  Retrieval  Storage  and  Display  Unit 


Figure  2.  Cartridge  Capability 
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Figure  3.  AEGIS  Maintenance  Sequence 
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Figure  6.  AEGIS  Maintenance  Manual  Hierarchy 
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Figure  7.  AEGIS  Maintenance  Manual  Hierarchy  (Continued) 
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Figure  8.  Concept  Definition,  Operational  Manuals 
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Figure  9.  Pamphlets  for  CSC  Operating  Manual 
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This  presentation  provides  an  overview  of  the  Specifications  and  Standards 
Application  Program  at  the  US  Army  Missile  Research  and  Development  Command 
(MIRADCOM),  Redstone  Arsenal,  AL,  The  presentation  is  based  on  the  Army 
Policy  contained  in  AR  700-70  and  as  cited  in  Appendix  1.  The  Specifica¬ 
tions  and  Standards  Application  Program  at  MIRADCOM  is  assigned  to  the 
Cqwand  Data  Management  Officer  (DM3), 

It  should  be  made  clear  that  the  MIRADCOM  Program  is  the  MIRADCOM  imple¬ 
mentation  of  AR  700-70,  All  Army  Commands  are  different;  therefore,  dif¬ 
ferences  in  program  implementation  exist,  Each  Army  Coftw©  has  implemented 
the  Specifications  and  Standards  Program  policies  with  slightly  different 
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MI 

My  PRESENTATION  DOES  NOT  CONTAIN  ANYTHING  NEW,  WE  AT  MIRADCOM  (AND  FORMERLY 
MICOM)  HAVE  USED  THIS  APPROACH  SINCE  1968.  SOME  OF  THE  TERMS  HAVE  CHANGED 
OVER  THE  YEARS  AND  TIGHTER  CONTROLS  HAVE  BEEN  IMPOSED,  BUT,  THE  BASIC  PRO¬ 
GRAM  HAS  REMAINED  UNCHANGED, 

I  FEEL  THAT  AFTER  I  HAVE  FINISHED  YOU  WILL  AGREE  THAT  WE  ARE  ONLY  USING  A 
COMMON  SENSE  APPROACH, 


I 


hue 


TO  MAKE  ANY  PROGRAM  WORK,  A  METHOD,  PLAN  OR  TECHNIQUE  MUST  BE  DEVELOPED 
AND  FOLLOWED.  At  MIRADCOM  WE  FELT  THAT,  IN  ORDER  TO  KEEP  OUR  REQUIREMENTS 

(Data  and  Acquisition  Management  Systems)  at  a  minimum,  we  must  first 
DECIDE  TO  WHAT  DEGREE  THE  PROGRAM  AT  MIRADCOM  SHOULD  BE  CONTROLLED. 

It  was  evident,  that  with  the  emphasis  placed  on  Data  Management  at  the 

TIME,  THAT  FIRM  CONTROLS  WOULD  HAVE  TO  BE  INVOKED.  THE  ASSIGNED  COMMAND 
IK)  WAS  HELD  RESPONSIBLE  FOR  DEVELOPING  AND  IMPLEMENTING  A  PROGRAM  THAT 
WOULD  INSURE  THAT  MICOM  (LATER  MIRADCOM)  REQUIRED  ONLY  THE  MINIMUM 
ACQUISITION  MANAGEMENT  SYSTEMS  AND  DATA  REQUIREMENTS, 


THE  FIRST  STEP  WAS  TO  DETERMINE  HOW  WE  COULD  INSURE  THAT  ONLY  THE  MINIMUM 
REQUIREMENTS  WERE  CITED  IN  RFP'S  AND  SUBSEQUENT  CONTRACTS.  THE  ARMY  DID 
REQUIRE  REVIEWS  ON  CONTRACTS  EXCEEDING  CERTAIN  DOLLARS  BY  A  DATA  REQUIRE¬ 
MENTS  Review  Board  (DRRB),  We  at  MICOM  found  the  Army  policy  to  be  lacking 
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IN  THE  CONTROLS  NEEDED  TO  INSURE  PROPER  REVIEWS  SO  WE  IMPLEMENTED  A  FEW 
OF  OUR  OWN,  WE  FIRST  REORGANIZED  OUR  DATA  REQUIREMENTS  REVIEW  BOARD  BY 
APPOINTING  ONLY  TOP  MANAGEMENT  TO  THE  BOARD  CHAIRED  BY  THE  CHIEF  ENGINEER 

(later  Director  of  Engineering,  MIRADCOM),  Then  we  set  the  types  of  efforts 

TO  BE  REVIEWED.  We  PLACED  IMPORTANCE  ON  THE  EFFORT  RATHER  THAN  THE  DOLLAR 

value.  Our  DRRB  reviews  all  Advanced  Development,  Engineering  Development 


and  First  Production  efforts. 


The  second  step  was  to  develop  an  outline  of  how  a  RFP/Contract  Statement 
of  Work  should  be  structured  and  its  basic  contents.  Along  with  this  a 
method  of  determining  and  justifying  requirements  was  developed.  This 
required  the  Program  Manager  to  develop  his  preliminary  Work  Breakdown 
Structure  (WBS)  and  preliminary  System  Specification  prior  to  the  prepara¬ 
tion  of  the  Statement  of  Work. 


The  format  in  which  we  require  all  Advanced  and  Engineering  Development 

EFFORTS  TO  BE  PREPARED  IS  SHOWN  IN  APPENDIX  2.  THE  OUTLINE  COVERS  ALL 
POSSIBLE  REQUIREMENTS  SO  IT  MUST  BE  TAILORED  TO  EACH  PROGRAM  BASED  ON  THE 

program  Preliminary  WBS  and  System  Specification.  Advanced  Development 

REQUIREMENTS  GENERALLY  ARE  NOT  BROKEN  BELOW  THE  SECOND  WBS  LEVEL, 


The  primary  method  MIRADCOM  uses  to  obtain  from  the  functional  areas  the 

INFORMATION  AND  REQUIREMENTS  NEEDED  TO  ASSURE  THAT  ADEQUATE  INPUTS  ARE 
FURNISHED  IS  THE  DATA  CALL,  APPENDIX  5  IS  A  TYPICAL  FORMAT  FOR  DATA  CALLS. 

Included  in  this  call  is  the  requirement  to  apply  only  the  minimum  essential 
Specifications  and  Standards, 


Specifications  and  Standards  imposed  must  be  certified  as  shown  in  Appendix  4. 
Certification  is  at  the  supervisory  level. 

The  RFP/Contract  Attacwent  at  Appendix  5  serves  tv*)  purposes  in  the  RFP/ 
Contract.  (1)  It  satisfies  the  requirements  of  ASPR  1-1201  and  (2)  it  puts 

INTO  ONE  PUCE  A  LISTING  OF  ALL  SPECIFICATIONS  AND  STANDARDS  IMPOSED, 

WHETHER  THEY  HAVE  BEEN  TAILORED  AND  A  REFERENCE  TO  WHERE  THEY  ARE  IMPOSED. 

The  THIRD  STEP  WAS  TO  DETERMINE  THE  RFP  FLOW.  THE  FLOW  AS  SEEN  IN  APPENDIX  6 
PROVIDES  THE  DM0  WITH  CORRECT  REVIEW  STEPS  AND  ALSO  DEPICTS  THE  REVIEWS  A 
PROCUREMENT  PACKAGE  IS  SUBJECTED  TO. 

The  MIRADCOM  DRRB  and  Command  DM0  are  not  overly  concerned  with  reviewing 
the  DD  Form  1423.  We  check  to  make  sure  its  complete  and  only  calls  out 

THOSE  DATA  REQUIRED  BY  THE  STATEMENT  OF  WORK.  We  ARE  HIGHLY  CONCERNED  WITH 
THE  REQUIREMENTS,  OR  TASKS,  SET  FORTH  IN  THE  STATEMENT  OF  WORK.  THEY  DRIVE 
THE  DATA. 


II 

APPLICATION  OF  SPECIFICATIONS  AND  STANDARDS 


Now  YOU  KNOW  BASICALLY  HOW  MIRADCOM  DETERMINES  AND  CONTROLS  THEIR  RFP 
REQUIREMENTS.  THE  APPLICATION  OF  SPECIFICATIONS  AND  STANDARDS  IS  AN 
INTEGRAL  PART  OF  THE  MIRADCOM  DATA  fV\NAGEMENT  PROGRAM.  BUT  WHAT  IS  IT? 


Application  is  defined  in  AR  700-70  as:  'The  orderly  process  of  reviewing 

AND  SELECTING  FROM  THE  TOTAL  REALM  OF  AVAILABLE  SPECIFICATIONS  AND  STANDARDS 
THOSE  THAT  ARE  CONSIDERED  TO  HAVE  APPLICATION  TO  THE  PARTICULAR  MATERIEL 
ACQUISITION  PROGRAM  AND  CONTRACTUALLY  INVOKING  THESE  WHOLLY/  OR  IN  PART/ 

AT  THE  MOST  ADVANTAGEOUS  STATUS  POINT  IN  THE  SYSTEM  DEVELOPMENT  CYCLE." 

VAtY  SO  MUCH  INTEREST  AND  EMPHASIS  ON  THE  PROPER  APPLICATION  OF  SPECIFICA¬ 
TIONS  and  Standards?  The  answer  is  better  explained  in  the  Defense  Science 
Boards'  "Report  of  the  Task  Force  on  Specifications  and  Standards"  dated 
April  1977/  better  known  as  the  SHEA  Report,  If  you  haven't  read  IT/  I 
highly  recommend  you  do  so,  For  your  benefit  I  have  extracted/  at  Appendix  7, 

THE  SHEA  FINDINGS  AND  THE  RECOMMENDAT I ONS  FOR  IMPROVED  APPLICATION. 

Based  on  the  SHEA  findings/  it  becomes  apparent  why  the  interest  and  emphasis 

IS  ON  THE  PROPER  APPLICATION  OF  SPECIFICATIONS  AND  STANDARDS, 

The  proper  Application  of  Specifications  and  Standards  should  begin  as  early 
as  possible  in  the  Program  Life  Cycle,  Decisions  can  be  made  as  to  when 
formal  Application  of  Specifications  and  Standards  are  required  and  how 
that  application  must  progress  by  charting  the  Program  Milestones  and 
determining  the  Program  Type  Designator  during  the  Program  Initiation  Phase, 

The  proper  Application  of  Specifications  and  Standards  is  the  responsibility 
of  the  individual  or  organization  imposing  the  requirement,  However/  con¬ 
trols  must  be  imposed  at  the  Command  level  (as  described  earlier)  to  pre¬ 


vent  misapplication. 


Before  1  go  into  some  of  tic  methods  of  Application  let  me  say  that  I  have 

AVOIDED  USING  THE  TERM  "TAILORING"  INTENTIONALLY.  TAILORING  IS  ONLY  ONE 
METHOD  IN  THE  APPLICATION  PROCESS  AND  IT  IS  NOT  THE  INTENT  OR  DESIRE  OF 
MIRADCQM  TO  TAILOR  SPECIFICATIONS  AND  STANDARDS.  THE  MI RADCOf  1  PROGRAM  IS 


THE  PROPER  APPLICATION  OF  SPECIFICATIONS  AND  STANDARDS  AS  DESCRIBED  IN  THE. 
DEFINITION  FOR  APPLICATION  IN  AR  700-70. 

There  are  many  ways  to  apply  specifications  and  standards,  some  of  which 
are  shown  in  Appendix  8.  MIRADCOH  primarily  pushes  the  "exception  method" 
although  some  good  use  of  the  "rewrite  method"  is  made.  Extracts  of 

ACTUAL  EXAMPLES  ARE  INCLUDED  IN  APPENDICES  9  THRU  13. 

We  have  started  the  Specifications  and  Standards  Application  Program  with 

A  GOOD  FOUNDATION;  HOWEVER,  IN  ORDER  TO  PROCESS,  THE  S1£A  RECOMMENDATIONS, 

Appendix  14.  must  be  enacted,  accepted  and  enforced. 

I  HOPE  I  HAVE  CONVINCED  YOU  THAT  DEFENSE  AGENCIES  ARE  PLACING  EMPHASIS 
ON  SPECIFYING  ONLY  MINIMUM  ESSENTIAL  REQUIREMENTS.  In  TWO  RECENT 
INSTANCES,  WE  AT  fllfWOT  ASKED  INDUSTRY  TO  COMMENT  ON  OUR  DATA  REQUIRE¬ 
MENTS  BY  MEANS  OF  A  DRAFT  REQUEST  FOR  PROPOSALS  (RFP).  Vfe  RECEIVED 
LITTLE  IN  THE  WAY  OF  SUGGESTIONS.  EITHER  WE  ARE  DOING  A  GOOD  JOB,  OR 
YOU  ARE  FAILING  TO  CHALLENGE  US.  THIS  EFFORT  NEEDS  TO  BE  A  TWO-WAY 
STREET.  WE  ARE  AWARE  THAT  NEITHER  GOVERNMENT  NOR  INDUSTRY  CAN  AFFORD 
SOME  OF  THE  LUXURIES  OF  THE  PAST.  I  SOLICIT  YOUR  CONTINUED  ASSISTANCE. 


ARMY  POLICY 
AR  700-70 


SPECIFICATIONS  AND  STANDARDS  USED  IN  MATERIAL  ACQUISI¬ 
TION  PROGRAMS  WILL  BE  SELECTIVELY  APPLIED  AND  TAILORED 
TO  IMPOSE  THE  MINIMUM  ESSENTIAL  NEEDS.  GENERALLY,  THE 
APPLICATION  AND  TAILORING  OF  SPECIFICATIONS  AND  STANDARDS 
AS  INTENDED  HEREIN  PERTAINS  TO  NONPRODUCT  SPECIFICATIONS 
AND  STANDARDS 


ARMY  POLICY 
(AR  700-70) 

•  MANAGEMENT  CONTROLS  OVER  USE  OF  SPECS  AND  STDS  AND  DATA 
ITEM  DESCRIPTIONS  TO  ASSURE  COST  EFFECTIVE  TAILORING 

•  CONTROL  OF  UNRESTRICTED  IMPOSITION  OF  TOTAL  SPECS  AND  STDS 

•  DATA  ITEM  DESCRIPTIONS  TO  BE  CONSISTENT  WITH  THE  TAILORED 
SOURCE  SPEC  OR  STD 

•  ESTABLISHMENT  OF  PROCEDURES  TO  PROVIDE  FEEDBACK  FROM 
PROSPECTIVE  CONTRACTORS 

•  MAINTENANCE  OF  TAILORING  REVIEWS  AND  RECORDS 

•  FUNCTIONAL  SUPPORT  GROUPS  TO  STRUCTURE  SYSTEM  AND  EQUIP¬ 
MENT  REQUIREMENTS  TO  BE  CONSISTENT  WITH  ARMY  POLICY  ON 
TAILORING 


•  REVIEW  BOARD  VERIFICATION  OF  TAILORING 

•  IMPOSED  REQUIREMENTS  TO  BE  CHALLENGED 


ENGINEERING  DEVELOPMENT 
SCOPE  OF  WORK 


WBS  LEVEL 


CLIN/PARA  NO. 


0001 AA 
0001  AA.1 


0001 AB 
0001  AB.1 

0001  AC 
0001  AC.1 
0001  AC.2 
0001  AC.3 

0001  AD 

0001AE 
0001  AE.1 
0001AE.1.1 
0001  AE.1 .2 
0001  AE.1. 3 
0001  AE.1 .4 
0001  AE.1 .5 
0001 AE. 2 
0001 AE. 3 
0001AE.4 
0001  AE. 5 
0001  AE. 6 


NOMENCLATURE 


SYSTEM  (DESCRIPTION) 

MISSILE 

(THIRD  LEVEL  TO  BE  DETERMINED  BY  ORIGINATOR 
IN  ACCORDANCE  WITH  MIL— STD  881  8t  AR  70-32) 

GROUND  SUPPORT  EQUIPMENT 

(THIRD  LEVEL  TO  BE  DETERMINED  BY  ORIGINATOR) 
TRAINING 

NEW  EQUIPMENT  TRAINING 
TRAINING  SERVICES 
TRAINING  FACILITIES 

PECULIAR  SUPPORT  EQUIPMENT 

SYSTEM  TEST  AND  EVALUATION 
DEVELOPMENT  TEST 
DESIGN  TESTS 

PREQUALIFICATION/RELIABILITY  TESTS 
HUMAN  FACTORS  ENGINEERING  TESTS 
SAFETY  TESTS 

SYSTEM  ASSESSMENT  EVALUATION 

TECHNICAL  EVALUATION 

TEST  AND  EVALUATION  SUPPORT 

OPERATIONAL  EVALUATION 

MOCK-UPS 

TEST  FACILITIES 


SCOPE  OF  WORK 


DATA  CALL 


SCOPE  OF  WORK,  DO  FORMS  1423 
DD  FORMS  1660,  DD  FORMS  1664, 
ADDENDA 


FROM:  DATE: 


TO:  DRXHC-MI  (HUMAN  FACTORS  ENGINEERING) 

DRDMI-QP  (QUALITY,  RAM,  RELIABILITY,  MAINTAINABILITY) 

DRDMI-EA  (PRODUCIBI LITY,  ENGINEERING  PLANNING) 

DRDMI-ESD  (ENG  DWGS,  STANDARDIZATION,  NOMENCLATURE.  SPECIFICA¬ 
TIONS,  CM) 

DRDMI-DC  (WBS,  FINANCIAL  REG,  DESIGN-TO-COST) 

DRDMI-ET  (TEST) 

DRDMI-T 

DRDMI-DP  (ALL  MIRCOM  REQUIREMENTS,  i.e.,  PUBS,  PROVISIONING,  PACK¬ 
AGING,  SAFETY,  TRANSPORTABILITY,  TRAINING,  LSA,  ETC.) 


SYSTEM: 

LENGTH  OF  CONTRACT: 

DOLLAR  VALUE: 

TYPE  CONTRACT:  (ENG  SVCS,  AD,  ED,  ETC.) 
CONTRACTOR  (IF  KNOWN). 

DD  FORM  1660  REQUIRED: 

DATE  REQUIREMENTS  NEEDED: 

TARGET  DATE  FOR  CONTRACT: 

IDENTIFY  TYPE  REVIEW  REQUIRED:  (DRRB  ETC.) 


ADDITIONAL  REMARKS: 


NOTE:  SCOPE  OF  WORK  SHALL  BE  PREPARED  IN  ORIGINAL  (AD&ED  SOW  WILL 
FOLLOW  WBS  FORMAT  OUTLINE).  DD  FORMS  1423  MAY  BE  IN  DRAFT  PROVIDED 
ALL  INFORMATION  IS  AVAILABLE.  DD  FORMS  1660  MAY  ALSO  BE  DRAFT.  DD 
FORMS  1664  NEED  NOT  BE  ATTACHED  UNLESS  MODIFICATION  HAVE  BEEN  MADE 
(ADDENDA  IS  NOT  CONSIDERED  MODIFICATION). 


SIGNATURE  OF  INITIATOR 


TELEPHONE  NO. 


SPECI FICATION/ST AND ARD  CERTI F ICATION 


DIRECTORATE/OFFICE: 

SUBMITTED  BY: _ 

OFFICE  SYMBOL: _ 

TELEPHONE  NO: 


THE  SPECIFICATIONS/STANDARDS  LISTED  BELOW  ARE  THE  MINIMUM 
ESSENTIAL  REQUIREMENTS  OF  THIS  DIRECTORATE/OFFICE.  EACH 
SPECIFICATION/STANDARD  HAS  BEEN  THOROUGHLY  REVIEWED  AND 
ONLY  THE  SPECIFIC  REQUIREMENTS  HAVE  BEEN  CITED. 

EACH  TAILORED  SPECIFICATION/STANDARD  IS  ANNOTATED  WITH  AN 
ASTERISK. 

THE  LIST  CONTAINS  ALL  APPLICABLE  FIRST  TIER  DOCUMENTS. 


DIRECTOR/CHIEF 


ATTACHMENT  TO  RFP/CONTRACT 


SPECIFICATIONS/STANDARDS  APPLICATION  LIST 


THE  FOLLOWING  FIRST  TIER  SPECIFICATIONS/STANDARDS  OF  THE  ISSUE  STATED 

ARE  HEREBY  APPLICABLE  TO  THE _  SYSTEM  RFP/CONTRACT 

NO. _ .  IN  ADDITION,  AND  UNLESS  OTHERWISE  STATED,  ALL 

DOCUMENTS  SPECIFIED  IN  PARAGRAPH  2  OF  THE  FIRST  TIER  DOCUMENTS  ARE  OF 
THE  ISSUE  CONTAINED  IN  THE  DEPARTMENT  OF  DEFENSE  INDEX  OF  SPECIFICATIONS 
AND  STANDARDS  (DODISS)  DATES  1  JULY  1978  WITH  SUPPLEMENT  DATED _ 


RFP  / 

DOCUMENT  NUMBER  REVISION  DATE  NOMENCLATURE  CONTACT  REFERENCE 


•DENOTES  DOCUMENT  THAT  HAS  BEEN  TAILORED.  RFP/CONTRACT  REFERENCE  WILL 
LIMIT  DOCUMENT  APPLICABILITY. 
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HARDWARE -DATA  8  100,000  + 


Figure  G-l.  Phase  I  (procurement)  data  requirements  package  flow 


SHEA  RECOMMENDATIONS 
IMPROVED  APPLICATIONS 


A.  LIFE  CYCLE  TAILORING 

B.  PREPARE  APPLICATION  GUIDELINES 

C.  IDENTIFY  AND  TAILOR  "COST  DRIVER"  SPEC/STDS 

D.  ENCOURAGE  CONTRACTORS  TO  SUBMIT  COST-EFFECTIVE 
ALTERNATES 

E.  ELIMINATE  PRO-FORMA  PLANS 

F.  DEVELOP  CONTRACTUAL  INCENTIVES  TO  ENCOURAGE 
TAILORING 

G.  CONTROL  PROLIFERATION  OF  NON-DODISS  TECH 
REQUIREMENTS  DOCUMENTS 


»v 


SHEA  REPORT  RECOMMENDATIONS 
IMPROVED  APPLICATIONS  (CONT'D) 


I.  DOD  SHOULD  INCORPORATE.  IN  ASPR  AND  IN  ITS  PLANNED  POLICY 
ON  APPLICATIONS  TAILORING,  PROVISIONS  WHICH  REQUIRE  SPECIFIC 
MANAGEMENT  ATTENTION.  CONTROLS  AND  LIMITS  OVER  THE  INCOR¬ 
PORATION  OF  DOCUMENTS  CALLED  OUT  BY  REFERENCE  IN  OTHER 
CITED  REQUIREMENTS  DOCUMENTS. 

J.  FOR  THE  ABOVE  RECOMMENDATIONS  TO  BE  EFFECTIVE.  DOD  MUST 
INSTITUTE  A  VIGOROUS  CAMPAIGN  TO  EDUCATE  BOTH  GOVERNMENT 
AND  CONTRACTOR  PERSONNEL  AND  TO  PUBLICIZE  THE  INTENT  OF 
DIRECTIVES  ISSUED  TO  IMPLEMENT  THE  IMPROVED  CLIMATE  OF 
APPLICATION. 
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"COST  DRIVER"  AREAS 
GREATEST  POTENTIAL  -  MISAPPLICATION  OF 
SPECIFICATIONS  &  STANDARDS 

•  GENERAL  DESIGN  REQUIREMENTS 

•  CONFIGURATION  MANAGEMENT 

•  HUMAN  ENGINEERING/SAFETY 

•  RELIABILITY  -  MAINTAINABILITY 

•  QUALITY  ASSURANCE 

•  ENVIRONMENTAL  REQUIREMENTS  &  TEST  METHODS 

•  DOCUMENTATION/STANDARDIZATION 

•  PACKING,  PACKAGING,  PRESERVATION,  TRANSPORT 

•  INTEGRATED  LOGISTICS 

•  MANUFACTURING  PROCESSES/METHODS 


METHODS  OF  TAILORING 
(HOW) 


•  USE  EXCEPTIONS 

•  REWRITE  PARAGRAPHS 

•  SPECIFY  QUANTIFIED  REQUIREMENTS 

•  SUPPLEMENT 

•  USE  THE  SPEC/STD  AS  A  GUIDE 

NOTE:  ASPR  1-1201  ALLOWS  ONLY  DOWNWARD 
TAILORING  OF  SPEC/STD. 
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APPLICATION  OF  SPECS/STDS 
HOW  (MIRADCOM) 


1.  BY  IMPOSING  ONLY  THE  MINIMUM  ESSENTIAL  REQUIREMENT  ON 
THE  CONTRACTOR. 

2.  BY  INSURING  THAT  THE  REQUIREMENT  IMPOSED  IS  COMPATIBLE 
WITH  THE  SYSTEM  LIFE  CYCLE. 

3.  BY  ALLOWING  SUFFICIENT  LEAD  TIME  IN  ORDER  THAT  THE 
CONTRACTOR  CAN  PERFORM  THE  FUNCTION  ROUTINELY. 

4.  BY  SPECIFICS  RATHER  THAN  GENERALITIES.  THUS  DECREASING 
THE  POSSIBILITY  OF  CHANGE. 

5.  BY  NOT  REQUIRING  PRELIMINARY  SUBMITTALS  OF  DATA, 
ESPECIALLY  FROM  CONTRACTORS  WHO  HAVE  HAD  PREVIOUS 
MIRADCOM  CONTRACTS. 


PROGRAM  MILESTONES 

O  -PROGRAM  INITIATION  PHASE 

I  -  DEMONSTRATION  AND  VALIDATION 

II  -  FULL-SCALE  ENGINEERING  DEVELOPMENT 

III  -  PRODUCTION  AND  DEPLOYMENT 

PROGRAM  TYPE  DESIGNATORS 

I  -  COMPLEX,  HIGH  QUANTITY 

II  -  NONCOMPLEX,  HIGH  QUANTITY 

III  -  COMPLEX,  LOW  QUANTITY 


IV  -  NONCOMPLEX,  LOW  QUANTITY 


u.  s.  ARmr 

miSSILE 

RESEARCH 

ROD 

DEVELOPmEnT 

commAfiD 


SCOPE  OF  WORK 

GENERAL  SUPPORT 
ROCKET  SYSTEM 

VALIDATION  PHASE 


Redsione  Arsenal,  AlaDama  35809 


17  JANUARY  1977 


UMI  rOf«4  1000.  1  APR  77 


0001  AF.1.C.  HUMAN  FACTORS  ENGINEERING  (PAGES  29,  30  &  31  GSRS  SOW) 

1.  A  HUMAN  FACTORS  ENGINEERING  PROGRAM  SHALL  BE  PLANNED  AND 
IMPLEMENTED  IN  ACCORDANCE  WITH  MIL-H-46855,  AS  APPLIED  TO  THE 
GSRS  VALIDATION  PHASE  OBJECTIVES,  CHARACTERISTICS  AND  CON¬ 
STRAINTS,  WITH  THE  FOLLOWING  EXCEPTIONS  (PARAGRAPH  NUMBERS  IN 

a.  THRU  m.  BELOW  ARE  THOSE  IN  MIL-H-46855A,  DATED  2  MAY  1972): 

a.  PARAGRAPH  3.1. 2.1  -  DELETE  "IN  ACCORDANCE  WITH  3.3"  FROM  THE 
SECOND  SENTENCE.  DELETE  THE  THIRD  SENTENCE  AND  SUBSTITUTE 
THE  FOLLOWING  "THE  HUMAN  ENGINEERING  PROGRAM  PLAN  SHALL 
BE  DIRECTED  TOWARD  HUMAN  ENGINEERING  REQUIREMENTS  FOR  THE 
FULL  SCALE  DEVELOPMENT  PHASE." 

b.  PARAGRAPH  3.1. 2.2  -  DELETE. 

c.  PARAGRAPH  3.1.2.3  -  DELETE. 

d  PARAGRAPH  3.2  -  THIS  PARAGRAPH  APPLIES  ONLY  TO  THE  EXTENT  THAT 
DETAIL  DESIGN,  DESIGN  REVIEWS  AND  ENGINEERING  CHANGE  PROPOSAL 
REVIEWS  ARE  APPLICABLE  DURING  THE  VALIDATION  PHASE  PROGRAM. 


HUMAN  FACTORS 


ENGINEERING  (CONT’DI 


e.  PARAGRAPH  3.2.2.2  -  FOR  PURPOSES  OF  THIS  PROVISION,  "DETAIL 
DESIGN"  REFERS  TO  ANY  DESIGN  OF  EQUIPMENT  TO  BE  DEVELOPED 

IN  ACCORDANCE  WITH  REQUIREMENTS  OF  THE  CONTRACT,  REQUIRING 
INTERFACING  WITH  PERSONNEL  FOR  OPERATION.  CONTROL  AND  MAIN¬ 
TENANCE. 

f.  PARAGRAPH  3.2  2.3  -  DELETE  "DETAIL"  IN  THE  FIRST  SENTENCE. 
DELETE  SUBPARAGRAPH  e. 

g.  PARAGRAPH  3.2.3  -  DELETE  tHE  LAST  SENTENCE. 

h.  PARAGRAPH  3.2.4  -  DELETE  THE  SENTENCES  IN  PARENTHESES. 

i.  PARAGRAPH  3.2.4.1  -  DELETE  THE  PORTION  OF  THE  FIRST  SENTENCE 
STARTING  WITH  "AND  SHALL  BE  INTEGRATED  INTO." 

j.  PARAGRAPH  3.2.4.2  -  DELETE  FROM  THE  FIRST  SENTENCE  THE  PHRASE 
"CONTAINED  IN  APPROVED  TEST  PLAN."  DELETE  THE  SECOND  SEN¬ 
TENCE. 

k.  PARAGRAPH  3.3  -  DELETE. 

l.  PARAGRAPH  3.4  -  OELETE. 

m.  PARAGRAPH  3.5  -  DELETE. 
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HUMAN  FACTORS  ENGINEERING  (CONT'DJ 


2.  THE  HUMAN  FACTORS  ENGINEERING  PROGRAM  SHALL  INCLUDE,  BUT  NOT 
NECESSARILY  BE  LIMITED  TO,  THE  FOLLOWING: 

a.  STUDIES  AND  ANALYSES  -  HUMAN  FACTORS  ENGINEERING  ANALYSES  SHALL 
INCLUDE  DEFINITION  AND  ALLOCATION  OF  SYSTEM  FUNCTIONS  TO  THE 
DEGREE  APPLICABLE  TO  GSRS  DEVELOPMENT,  PRELIMINARY  EQUIPMENT  IDEN¬ 
TIFICATION,  ANALYSIS  OF  TASKS  AND  PRELIMINARY  SYSTEM  DESIGN. 

HUMAN  ENGINEERING  PRINCIPLES,  CRITERIA  AND  THE  RESULTS  OF  TESTING 
SHALL  BE  APPLIED  WITH  OTHER  DESIGN  REQUIREMENTS  TO  IDENTIFY  THE 
EQUIPMENT  TO  BE  USED  BY  MAN.  THE  DESIGN  CONFIGURATION  SHALL  REFLECT 
HUMAN  FACTORS  ENGINEERING  INPUTS  TO  SATISFY  THE  SYSTEM  PERFORMANCE 
REQUIREMENTS  AND  THE  APPLICABLE  CRITERIA  OF  Ml L-STD-1472B. 

b.  DETAILED  DESIGN  -  HUMAN  FACTORS  ENGINEERING  APPLICATION  TO  DETAILED 
DESIGN  SHALL  BE  DIRECTED  TOWARD  SATISFYING  REQUIREMENTS  IN  THAT 
AREA  SPECIFIED  BY  MIL-H-46855  IN  GENERAL  AND  TOWARD  THE  FOLLOWING 
CRITICAL  FUNCTIONS  IN  PARTICULAR: 

(1)  SPLL  DESIGN  -  MAN/MACHINE  INTERFACE  DESIGNED  TO  MINIMIZE  CREW 
SIZE  AND  PHYSICAL  EFFORT  REQUIRED  TO  MEET  SPECIFIED  REACTION  TIME. 

(2)  CREW  TASK  SEQUENCE  -  GSRS  FIRING  AND  RELOAD. 


HUMAN  FACTORS  ENGINEERING  (CONT’D) 


(3)  FIRING  ENVIRONMENT  -  NOISE  PER  CRITERIA  OF  MIL-STD-1474A,  HIGH 
VELOCITY  PARTICLES,  VISIBLE  ENERGY,  EXHAUST  PRODUCTS  AND  THER¬ 
MAL  ENERGY  EFFECTS. 

(4)  FIELD  OPERATION  -  EFFECTS  OF  PERSONNEL  EQUIPMENT,  CLOTHING, 
CLIMATIC  CONDITIONS,  DEGRADED  VISIBILITY/ILLUMINATION  CONDI¬ 
TIONS,  AND  TERRAIN. 

c.  HFE  DESIGN  CRITERIA  -  PERFORMANCE  CRITERIA  TO  BE  USED  SHALL  BE 
THAT  HUMAN  PERFORMANCE  NECESSARY  TO  MEET  OR  EXCEED  THE  SYSTEM 
CAPABILITIES  SPECIFIED  BY  MIS  26432.  HFE  DESIGN  SHALL  CONFORM  TO 
APPLICABLE  REQUIREMENTS  MIL-STD-1472B,  "HUMAN  ENGINEERING  DESIGN 
CRITERIA  FOR  MILITARY  SYSTEMS,  EQUIPMENT  AND  FACILITIES." 

d.  HFE  TEST  AND  EVALUATION  -  INTEGRATION  OF  HUMAN  FACTORS  ENGI¬ 
NEERING  REQUIREMENTS  INTO  TESTING  TO  DEMONSTRATE  (1)  REACTION 
TIME  FOR  EMPLACEMENT,  FIRE  MISSION,  RESUPPLY  AND  MARCH  ORDER, 

(2)  PERFORMANCE  ACCURACY  FOR  CRITICAL  TASKS  AS  DEFINED  BY  6.2.1  OF 
MIL— H— 46855A,  AND  (3)  SUITABILITY  OF  DEVELOPED  OPERATING  PROCEDURES. 

a.  FORMULATION  OF  A  PROPOSED  HUMAN  FACTORS  ENGINEERING  PROGRAM  PLAN 
FOR  FULL  SCALE  DEVELOPMENT. 
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4.3.1  Quantitative  Requirements 

5.2.2  of  A. 2. 6  Diagnostic  Capability  Analysis  (DCA) 

5.2.3  of  A. 2. 6/A. 2. 12  Repair  Method  Analysis  (RMA) 
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5.2.7. 2  Engineering  Design  Changes 

5. 2. 7. 3  Reliability  Analysis  of  Proposed  Engineering  Changes 

5.3.2  Development  Testing 

5.3.3  Reliability  Demonstration 
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FUTURE  NEEDS 


1.  FOCUS  AND  STRENGTHEN  DOD  MANAGEMENT  OF  SPECIFICATIONS. 
WITH  INITIAL  CONCENTRATION  ON  COST-DRIVING  REQUIREMENTS. 

2.  IMPROVE  FEEDBACK  FROM  USERS  TO  PREPARERS. 

3.  CONTROL  SPECIFICATION  GENERATION  AND  REVISION. 

4.  FOSTER  INCREASED  USE  OF  COMMERCIAL  SPECS/STDS. 

5.  REFORMAT  DOCUMENTS  TO  FACILITATE  TAILORING. 

6.  DEVELOP  NATIONAL  STANDARDS  WHICH  SATISFY  MILITARY 
REQUIREMENTS. 

7.  CHANGE  IN  PROPOSAL  EVALUATION  PROCESS. 


8.  CHANGE  PERSONAL  OPINIONS 


9.  TRAINING 


ROBOTICS  IN  MANUFACTURING 


VERN  ESTES 

General  Electric  Company 


NOTE:  This  paper  was  transcribed  from  a 

recording  of  the  session.  Unfortunately, 
it  was  not  possible  to  verify  the  spelling 
of  robot  brand  names  prior  to  the  publica¬ 
tion  deadline. 


'  nave  commented  that  I  probably  have  charge  of  the  largest  robo¬ 
tics  laboratory  in  the  United  States.  I  presently  have  ten  ro¬ 
bots.  T-t  is  of  interest  because  in  April  of  1977  General  Elec- 
t:  >c  had  olv  ten  robots  total.  Today  we  have  S3  operating  robots 
and  ten  .ry  la  os.  As  of  May  31,  during  our  seminar,  we  will 
nave  sev  •  >  teen  on  display. 

I  -hink  .•  a  should  know  where  I  come  front  I  am  from  a  Corporate 
Consult  in Services  Group  (an  ivory  tower,  of  sorts).  My  robotics 
laboratory  happens  to  be  in  the  oldest  building  in  General  Elec¬ 
tric.  I  eiieve  it's  Edison's  first  building  and  was  built  in 
1 odo-- the t  ' s  where  the  robots  are.  It  is  located  in  Schenectady, 
dew  York.  I  tnink  Edison  would  be  kind  of  proud  of  us. 

Just  a  little  bit  about  General  Electric:  we  do  '.lake  everything 
ftom  turbines  to ' toothbr ushes--we  cut  the  bristles,  put  them  in 
the  brushes  and  then  trim  them  to  length  for  our  electric  tooth¬ 
brush. 

how  where  Jo  we  tit  in  the  service  organization.  We  are  kind  of  a 
catalyst  lie  tween  all  of  the  operating  components  in  a  very  decen¬ 
tralized  company.  Probably  for  every  component  that  you  know  in 
the  General  Electric  Company,  I  would  name  ten  other  operating 
components  that  you  don't  know  anything  about. 

The  mission  of  my  group  is  to  assist  the  Company  in  maintaining  a 
cost  leadership  through  application  of  the  latest  advanced  manufac¬ 
turing  technology.  Today,  one  of  the  biggest  buzz  words  is  "robo¬ 
tics"  and  they  are  not  the  type  that  walk  around  the  floor.  We 
have  a  worldwide  monitoring  organization  and  that's  how  we  pick  up 
what  others  are  doing  in  other  countries.  'We  try  to  keep  track  of 
what  our  competition  is  doing  and  try  to  get  in  at  the  right  time 
on  these  new  technologies. 

We  discovered  what  other  companies  in  other  countries  were  doing 
with  robotics  a  couple  of  years  ago.  That  triggered  our  interest 
and  got  us  started  in  putting  together  this  lab.  I've  given 
thirty-one  presentations  to  my  own  company  and  surveyed  forty- 
five  of  our  operating  components  for  application  of  robots.  The 
big  thing  with  robots  and  the  reason  for  them  today  is  our  produc¬ 
tivity  is  lagging  in  the  United  States  in  relation  to  other  coun¬ 
tries.  I  just  came  back  from  Japan  as  part  of  our  worldwide 
monitoring  program  this  last  Saturday. 


Another  reason  for  our  concern  is  that  we  have  an  awful  lot  of 
machine  tools  in  the  General  Electric  Company,  probably  as  many  as 
any  other  major  manufacturing  facility  in  the  Unites  States.  We 
have  been  working  on  the  thirty  percent  side  of  our  machine  tool 
productivity  for  years.  We've  doubled  speeds  and  we've  doubled 
speeds,  that's  like  beating  a  dead  horse,  because  that's  only  the 
thirty  percent  side.  You've  got  to  work  on  the  seventy  percent 
side,  the  nonproductive  area,  nonchip  cutting,  the  handling  of 
parts,  getting  there  in  a  timely  manner  and  things  like  this, 
tying  everything  together  with  computers.  That’s  part  of  my 
operation — computer  managed  parts  manufacturing — and  robots  fit 
right  in. 

The  other  reason  for  robots  today  is  that  it  is  a  mature  technol¬ 
ogy.  People  who  tried  to  implement  robots  three,  four,  five  years 
ago  found  many  problems.  Today,  robots  are  very  smart.  In  fact 
in  my  labs,  I  have  two  of  the  smartest  robots  in  the  world.  I 
have  the  Cincinnati  Milacron  which  happens  to  have  a  minicomputer 
and  the  new  Puma  which  was  developed  for  General  Motors.  The  Puma 
has  eight  microprocessors  in  it.  They  are  much  easier  to  program 
than  they  used  to  be.  You  can  store  and  access  multiple  pro¬ 
grams;  in  other  words  if  you  have  parts  coming  by  on  a  conveyor 
you  can  do  something  different  on  each  part  as  it  comes  by.  If 
you  are  paint  spraying  for  instance,  the  parts  can  all  be  of 
different  conf igurations;  they  can  even  be  of  different  color, 
because  you’ve  got  many  different  programs  that  you  can  access. 
These  robots  will  even  keep  up  with  a  moving  conveyor  of  varying 
speed  and  in  some  cases  even  if  the  conveyor  reverses  it  will  keep 
doing  its  particular  function  on  that  part.  Up  to  seven  axis  of 
motion  are  possible  and  they  are  more  accurate  than  they  ever 
were. 

There  are  many  people  calling  these  robots  "universal  transfer 
devices",  "flexible  automation",  etc.  All  this  is  a  bunch  of 
garbage,  in  my  opinion,  because  they're  just  plain  industrial 
robots.  There  is  no  other  name  for  them.  You  can  call  them 

anything  else  and  it  ain't  gonna  work.  In  fact,  our  industrial 
psychologist  told  us  that.  But,  they  are  also  process  oriented. 
They  will  do  paint  spraying,  welding,  wire  laying,  and  routing. 
They  are  spot  welding  all  of  your  automobiles  together  these  days. 

If  we  want  to  talk  about  benefits,  here's  what  we're  realizing: 
twenty  to  twenty-five  percent  productivity  improvement.  Robots 
don't  go  to  the  bathroom,  they  don't  take  coffee  breaks,  they  just 
keep  working.  And  if  you  want  to  talk  about  return  on  investment, 
that's  excellent  too.  If  you  want  to  talk  about  what  it  can  do 
for  you  in  the  OSHA  area;  it  is  kind  of  interesting  that  we  had  an 
OSHA  citation  the  other  day.  The  only  comment  they  had  was  the 
robot  was  unloading  the  die  cast  machine  and  there  was  water  be¬ 
tween  the  robot  and  the  machine.  My  suggestion  was  to  give  the 
robot  a  vacuum  cleaner,  a  wet  vacuum,  and  let  it  vacuum  the  water 
up.  There  was  nobody  in  there  anyway,  so  I  don't  know  why  we  were 
worrying  about  it. 


Typical  appl ications:  at  Vern's  Robot  Farm,  there's  a  Cincinnati 
robot  that  loads  and  unloads  a  lathe.  In  fact,  a  robot  runs  the 
lathe.  It  tells  it  when  the  door  should  open;  a  sensor  says  the 
door  did  open,  it  can  come  down  inside,  etc. 

People  tell  me  that  robots  can't  keep  up  with  humans.  That's  a 
bunch  of  garbage.  If  it  is  a  properly  engineered  implementation 
of  a  robot,  it  can  keep  up  with  humans  and  work  circles  around 
them.  If  you  find  that  the  human  was  handling  two  parts  simulta¬ 
neously,  that's  what  you  have  to  do  with  a  robot.  It's  a  very 
efficient  operation.  In  fact  in  one  of  our  applications,  the 
robot  handles  the  job  so  efficiently  that  the  robot  got  kind  of 
bored  and  we  had  to  have  it  change  hands,  let  it  pick  up  a  welding 
gun,  and  do  a  TIG  welding  operation.  In  fact,  a  year  ago  I  was 
told  that  this  robot  was  not  accurate  enough  to  do  TIG  welding. 

My  ignorance  of  some  of  these  processes  tells  me  to  try  it.  After 
I  did  TIG  welding,  they  came  back  and  told  me  I  couldn't  do  TIG 
welding  that  required  more  accuracy.  By  the  way,  we're  the  first 
in  the  United  States  to  do  TIG  welding  with  a  robot. 

Some  examples  of  what  robots  are  doing  are  welding,  paint  spray¬ 
ing  (if  you  buy  a  General  Electric  refrigerator  these  days  it  may 
have  been  sprayed  by  a  robot,  and  we  spray  the  welded  seams  of  the 
liner  on  a  moving  converyor  with  a  robot),  and  deburring  opera¬ 
tions.  Some  robots  are  known  for  their  repeatability  within  0.010 
inch.  That's  a  $75,000  robot  and  it  may  go  to  $150,000.  They  are 
not  cheap,  but  they  are  very  effective.  One  such  robot  is  a 
Unimate  robot  in  Toronto,  Canada  at  International  Harvester  that 
loads  and  unloads  a  heat  treating  furnace.  (There  were  some 
articles  in  recent  magazines  on  that  one.)  Other  Unimates  load 
and  unload  plastic  molding  machines.  If  you  buy  a  GE  coffee 
maker  these  days,  the  plastic  components  for  that  coffee  maker 
could  have  been  unloaded  from  the  plastic  molding  machine  by  robot 
with  tender  lovng  care,  by  the  way.  Robots  are  being  used  to  load 
and  unload  large  presses.  Here  is  an  area  in  which  we  have  a 
serious  problem  with  OSHA.  These  presses  make  noise,  there  is  no 
question  about  it.  This  is  one  way  to  solve  the  problem.  You 
take  the  people  out,  put  the  robots  in,  and  close  the  area  to 
humans. 

We  have  used  a  robot  to  operate  a  standard  milling  machine.  All 
they've  done  is  put  a  hydraulic  clamping  device  on  it.  In  fact 
the  robot,  even  comes  over  (there's  a  film  on  this)  and  hits  the 
speed  lever  to  start  it.  This  was  in  our  labs  last  year. 

We  are  holding  our  third  annual  seminar  for  GE  people  on  May  31. 
The  first  year  (1977)  when  we  held  that  seminar,  we  had  thirty- 
five  attendees  and  four  robots.  Last  year,  we  had  eighty-seven 
attendees  and  eleven  robots.  This  year,  when  I  left  the  plant  on 
Monday,  we  had  one  hundred  people  signed  up  and  we  have  seventeen 
robots  for  this  seminar,  some  of  them  coming  in  on  consignment  for 
the  two  days. 


There  is  a  robot  with  a  GE  solid-state  camera  in  it.  That  camera 
is  used  to  inspect  the  features  of  an  automotive  carburetor.  The 
robot  will  accept  or  reject  the  carburetor  and  we  could  even  have 
another  robot  put  the  good  ones  down  one  line  and  the  others  down 
another  line. 

Another  robot  loads  a  forging  press--this  baby  is  no  dummy.  It 
comes  over  and  dips  its  hand  in  water  every  once  in  awhile  to  cool 
off.  It's  very  flexible;  you  can  make  it  do  almost  anything. 

The  Japanese  are  noted  for  their  use  of  robots.  In  fact,  last 
week  I  saw  them  using  robots  to  track  eddy  current  during  a  weld¬ 
ing  operation.  We're  taking  a  lot  of  interest  in  that  because 
the  robots  that  we're  using  for  welding  do  not  track  the  seam.  We 
are  going  to  use  robots  for  welding  in  the  General  Electric  Com¬ 
pany,  including  welding  one-of-a-kind  parts.  We  have  a  very  large 
welding  program  in  .ay  labs  this  year. 

Now,  how  do  you  program  these  things?  Well,  tn  is  gentleman  right 
here  is  programming  a  Tralfa  robot.  Tralfa  robots  are  built  in 
Norway  by  a  wheelbarrow  manufacturer  to  paint:  spray  wheelbarrow 
bottoms  an  a  conveyor.  This  robot  happens  to  be  accurate  to  U.Q06 
inch  according  to  tests  run  by  Lockheed.  One*'  programmed,  micro¬ 
processors  store  the  program  on  floppy  disks.  This  re. hot  will 
store  04  different  programs. 

This  gent  lemam  is  using  dependent  control  to  i.gi  ...  Cincin¬ 

nati  robot.  It  will  handle  300  pounds,  has  six  ax  of  control, 
and  is  worth  $66,00 u.  It  is  the  second  smartest  :  ->t  in  the 
wot  Id  t.  ight  now. 
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you  call  it  anything  else.  So  we  call  them  robots  and  most 
everybody  else  is  calling  them  robots  these  days. 

We  also  came  up  with  a  "dumb  mistakes"  list  as  a  part  of  the  phy- 
chological  report.  The  phychologist  determined  that  it  was  not 
the  hourly  people  that  are  surpressing  this  technology.  (Believe 
me  we  didn't  just  explore  within  GE--we  looked  inside  GE,  outside 
GE,  and  places  where  they  had  robots  that  were  both  successful  and 
failures.)  He  found  out  that  the  thing  that  was  surpessing  this 
technology  was  the  conflict  between  manufacturing  engineering  and 
shop  management.  It  was  a  shock  at  first,  but  then  I  began  to 
realize  how  that  could  happen.  Now  we  have  added  a  second  phase 
to  our  psycholoc ical  impact  study:  the  management  aspect. 


Very  early  in  the  game,  I  realized  that  there  were  some  rules  of 
thumb  that  were  important  (Production  Automation  Magazine  will 
soon  publish  my  list).  One  thing  I  don't  think  I  have  to  explain 
is  why  I  recommend  putting  them  in  a  hostile  environment.  That's 
the  easiest  place  to  implement  the  robot  and  where  we  have  been 
very  successful. 

Robots  are  truly  productivity  improvers.  If  you  listen  to  our 
President  at  the  General  Electric  Company,  you  will  know  that 
productivity  is  the  number  one  priority.  Twenty  to  twenty-five 
percent  productivity  improvement  has  been  our  experience. 

In  developing  a  plan  to  implement  robotics,  evaluate  your  long¬ 
term  needs.  Don't  go  in  and  start  throwing  them  here  and  there 
and  get  one  each  of  all  the  different  brand  names.  What  I  mean  by 
this  is  evaluate  all  of  your  robotic  needs.  For  every  vendor 
brand  that  you  put  in,  you  buy  a  tester,  a  recorder,  and  you  buy 
spare  parts.  So  if  you  have  a  number  of  brand  names,  you've  got 
a  lot  of  duplication  of  costs.  Implementation  costs  are  indirect 
ly  proportional  to  the  cost  of  the  robot.  My  definition  of  a  ro¬ 
bot  is,  it's  a  cominer  ical  ly  available  device  that  is  reprogram¬ 
mable  and  a  few  things  like  that.  They  produce  everything  from 
auto  license  plates  which  are  very  simple  to  the-  most  sophisti¬ 
cated  computer-controlled  unit.  When  you  put  one  of  the  simple 
devices  in,  it  has  a  fixed  extension,  fixed  attraction,  fixed  up, 
fixed  down  and  fixed  adjustable  stops.  The  sequence  is  the  only 
thing  that  varies.  Sometimes  it  is  a  lot  more  expensive  to 
install  an  inexspensive  one  than  it  would  be  to  install  one  that 
costs  $10,000  more. 

When  I  go  to  evaluate  applications  of  this  technology  for  our 
operating  components,  they  tell  me,  "Well  you're  from  Corporate 
and  yo want  to  get  into  the  complex  stuff."  I  say,  "I'm  a 
Manufaot  .:r  ing  guy,  not  too  smart  or  I  probably  wouldn't  have 
stayed  in  this  fie!-.]  frr  so  long."  I  want  to  start  in  the  simple 
areas  because  1  can't  afford  failures.  Murphy's  Law  very  much 
applies  'ere.  As s  me  ‘.'oat  it  it  can  happen,  it  will  happen.  One 
of  our  operating  c.  npenents  came  back  to  me  about  six  times  this 
year  because  the  part  wouldn't  always  come  our  the  d i o .  What 

am  I  gonna  do?  I  suggested  getting  an  inject  or  in  therc--there 
is  no  other  solution.  He  came  back,  in  fact  keeps  coming  back 
asking  the  same  questions,  but  he  doesn't  implement  the  solution 
so  I  can't  help  him  very  much.  Sensors  is  the  name  of  tine  game 
in  this  technology.  As  soon  as  you  take  the  human  out,  you've 
lost  a  very  sophisticated  piece  of  equipment. 

Don't  expect  your  vendors  to  do  it  all  for  you  either.  "Turnkey" 
is  a  bad  word.  "Integrated  turnkey"  is  what  we  are  talking  about 
these  days.  A  sophisticated  system  requires  you  to  be  as  responsi 
ble  as  your  vendor. 

Last,  but  not  least,  don't  forget  the  people  requirement.  People 
say  to  me,  "Well,  how  are  you  going  to  maintain  them?"  I  say  if 
you  do  a  bad  job  up  front,  you  will  have  problems.  Our  company 
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went  out  and  hired  an  electronics  technician  because  they  saw 
electronic  controls  on  the  robot  and  they  didn't  understand  them. 
What  did  they  do  about  the  aspects?  They  did  absolutely  nothing. 
They  didn't  even  tell  their  mechanical  maintenance  personnel  that 
they  could  adversely  effect  equipment  accuracy  on  a  permanent 
basis  by  improper  maintenance.  You've  got  to  train  personnal  to 
maintain  the  robots  properly. 

Many  questions  that  come  up  are  on  quality.  The  automotive  compa¬ 
nies  say  they  have  better  quality  then  they  ever  had  before.  They 
don't  have  to  put  extra  spot  welds  in  because  the  robots  are  too 
dumb  to  realize  that  it's  Monday  morning  and  they  didn't  go  out  on 
the  week-end,  so  they  put  in  all  the  spot  welds.  It  isn't  neces¬ 
sary  to  overlap  the  material  as  much  anymore  so  they  save  a  lot  of 
material.  Robots  don't  get  bored  and  the  quality  doesn't  change — 
they  are  reliable.  They  are  operational  ninety-eight  percent  of 
the  time  and  they're  easy  to  maintain.  If  they  weren't  reliable, 
they  wouldn't  be  hanging  arouund  in  Ford  Motor  Company  and  there's 
236  of  them  there  and  150  in  General  Motors  and  100  in  Chrysler. 

My  conclusion  with  this  technology  is  that  the  technology  is 
mature.  What  is  maturing  is  applications  engineering.  Our  Vice 
President  came  through  one  day  and  asked  why  I  was  promoting  the 
robot,  they  can't  keep  up  with  humans.  I  said  I've  got  news  for 
you.  If  it's  a  properly  engineered  implementation,  they  can  work 
circles  around  humans.  I  pointed  to  the  dual  gripper  hand  and 
the  fact  that  we  pick  a  couple  of  parts  up  simultaneously  to  meet 
five  second  cycles,  and  I  said  that's  what  it's  all  about.  The 
engineering  of  the  implementation  is  important. 

If  you  have  any  questions,  I  would  be  more  than  happy  to  answer 
them.  Thank  you. 
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The  presentation  addresses  a  fundamental  philosophical  issue  concerning 
Configuration  Management.  It  deals  with  the  need  to  upgrade  the 
discipline  to  adequately  perform  the  "technical  and  administrative 
surveillance  role"  and  to  place  the  "task"  role  of  Configuration 
Management  in  proper  prospective.  The  objective  is  to  promote  the 
management  responsibilities  of  Configuration  Management  by  establishing 
a  proper  charter  within  our  basic  directives,  recruitment  and  training 
of  technically  oriented  people  and  development  of  the  management  short 
fall. 
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APPLICATIONS  IN  CONFIGURATION  MANAGEMENT 

The  definition  of  configuration  management  as  contained  in  AFR  65-3 
relates  to  a  management  process.  From  that  point  forth,  however,  the 
regulation  addresses  configuration  task  elements  of  CM  with  relatively 
little  emphasis  on  management.  In  the  eyes  of  many  and  often  in  practice, 
configuration  "management"  equates  to  merely  performing  these  task  elements. 

By  implication  it  reduces  itself  to  a  clerical  function  of  participating 
in  and  recording  events.  There  are  many  who  are  quite  content  to  be 
configuration  recorders  and  not  configuration  managers.  If  configuration 
recording  is  the  true  function,  I  submit  that  most  configuration  managers 
are  grossly  overpaid.  There  is  much  that  is  not  done  or  done  by  someone 
else  if  a  conf iguration  "manager"  limits  himself  to  performing  within  the 
task  confines  of  AFR  65-3. 

I  view  configuration  management  involving  three  elements:  Administrative, 
Clerical,  and  Technical  management.  As  the  clerical  and  administrative 
functions  are  well  understood,  I  will  limit  the  remaining  remarks  to  techni¬ 
cal  management. 

If  one  is  to  manage,  he  must  have  a  resource  to  apply  to  affect  a  solution. 
That  resource  may  be  expertise,  manpower  or  authority.  Ideally  it  is  all  of 
these.  An  effective  manager  tends  to  influence  the  outcome  of  an  event  in  a 
positive  and  productive  manner.  If  one  accepts  this  workaday  definition, 
there  are  few  configuration  managers  that  truly  manage.  Part  of  the  .reason 
is  that  the  management  charter  is  not  defined  in  AFM  65-3  and  partly  because 
of  the  preponderance  of  non-techni cal ly  oriented  people  within  CM. 

Configuration  Management  grew  from  and  is  still  essentially  a  subdiscipline 
of  engineering.  While  engineering  is  responsible  for  item  performance,  CM 
is  responsible  for  documenting  that  performance.  The  Configuration  Manager's 
main  interface  throughout  the  development  of  a  program  is  essentially  with 
engineering  or  dealing  with  the  products  of  engineering.  In  the  ASD  environ¬ 
ment  we  have  found  that  generally  the  technically  oriented  CM  does  a  better 
job  than  a  non-technical  CM  and  specifically  the  CMs  who  are  engineers  tend 
to  do  the  best  job.  The  reason  seems  to  be  that  there  is  no  credibility 
gap  when  dealing  engineer  to'  engineer  and  that  the  depth  of  understanding 
the  technical  proolem  tends  to  be  higher,  hence  stimulating  questions/ 
discussions  which  tend  to  lead  to  better  CM  performance.  There  are  also 
many  intangible  benefits  to  be  gained  from  this  arrangement.  While  I  do 
not  advocate  that  every  CM  be  an  engineer,  I  do  feel  that  CMs  should  have 
a  good  technical  background  and  that  these  be  supplemented  with  clerical 
or  administrative  skills  or  configuration  assistants  at  appropriate  grade 
levels . 

With  a  base  of  technical  CM  personnel  we  could  better  address  the 
technical  management  issue.  While  the  Program  Manager  is  ultimately 
responsible  for  all  aspects  of  a  program,  in  at  least  the  ASD  environ¬ 
ment,  he  has  tended  to  turn  to  engineering  for  all  things  technical 
including  technical  management.  The  result  in  many  cases  has  been  where 
engineering  has  done  as  much  configuration  (technical)  management  as  they 


have  in  ensuring  item  performance.  Engineering  generally  writes  the  System 
Specification  while  all  parties  contribute  to  the  Statement  of  Work.  The 
project  manager,  particularly  if  assigned  to  numerous  programs,  may  not  have 
time  nor  necessarily  be  technically  qualified  to  make  a  thorough  review  of 
the  two  documents  to  ensure  that  they  are  reflective  of  each  other,  that 
they  are  integrated  from  a  management  viewpoint  and  that  they  adequately 
communicate  to  the  potential  contractor  the  technical  tasks  to  be  done. 

Such  technical  management  assessment  from  the  CM  together  with  the  perfor¬ 
mance  assessment  from  engineering  could  allow  the  project  manager  more 
time  to  devote  his  attention  to  total  program  considerations. 

Configuration  Management  has  impact  at  each  milestone  of  a  program. 

The  scope  of  this  involvement  is  not  necessarily  limited  to  the  following 
paragraphs.  The  program  event  sequence  is  as  specifically  applied  to  small 
programs  to  simplify  explanation.  Large  programs  incorporate  the  same 
basic  elements  but  the  sequence  of  certain  milestones  may  vary  or  be  repeated 

Receipt  of  Form  56  (PMD) 

Pre-program  strategy  meeting 
Scope  of  effort 
Direction 

CM  Manpower  availability 
Estimated  Manhour  expenditure 
Program  milestone  structure 

System  Specification  (Tech  Exhibit)  -  CM  Coordination 
Is  it  manageable? 

Is  it  integrated  with  another  project? 

Does  it  flow  logically? 

Interfaces  stated? 

Limited  to  statements  about  performance  of  the  equpment? 

Ground  rules  for  quality  and  testing  included? 

Sufficient  to  drive  the  contractor  part  1  spec? 

Statement  of  Work  (SOW)  -  CM  Input  and  Coordination  *Section  J 

of  contract  if  no  SOW 
Is  performance  criteria  reflective  of  CM? 

Is  documentation  addressed? 

Are  schedules  addressed? 

Is  criteria  stated  that  clearly  convey  to  the  contractor 
what  constitutes  successful  completion  of  PDR,  CDR, 

FCA ,  PCA ,  etc? 

Configuration  Mgmt.  Plan/CRMP  -  Input  to  PMP.  Statement  of  CM 

considerations . 

How  to  handle  ECPs 
How  to  handle  Interfaces 

Is  construction  consistent  with  AFR  800-3? 

Purchase  Request  (PR)  -  CM  Coordination 

Does  PR  include  elements  that  satisfy  CM  requirements? 

Pre  RFP  Data  Review  -  Consolidate  CM  requirements 

Review  strategy  and  input  prior  to  release  of  RFP 


Post  RFP  Review  -  Consolidate  CM  requirements 

Assess  reasonability  of  contractors  submittal 
Prioritize  negotiating  priorities 
Review  contractors  preliminary  CM  plan 

Precontract  Negotiation 

Clear  statements  of  requirements 
Clear  milestone  definitions 
Establish  functional  baseline 

ECP  required  for  future  functional  baseline  changes 
Post  Contract  Review 

Convey  to  contractor  counterpart  understanding  of  the  contract. 
Ensure  contractor  understands  ECP  requirement  for  changes 
to  Sys.  Spec. 

Preliminary  Design  Review  (PDP.)  *may  require  iteration 
Approve  Contractor  CM  Plan 

Approve  Contractor  Drawing  structure.  (Contractor  should 
have  completed  most  of  the  conceptual  drawings  -  guide 
at  80%). 

Approve  Development  Specs,  if  in  concert  with  Sys.  Specs. 
Establish  allocated  baseline. 

ECP  required  for  future  development  Spec,  changes. 

Critical  Design  Review  (CDR) 

Approve  update  of  CM  plan 

Production  drawings  should  be  well  along  (guide  at  80%). 

Review  draft  of  Product  Spec,  to  track  with  Devel.  spec. 

Functional  Audit  -  In  most  cases  can  incorporate  the  FOR. 

Accomplished  after  Qual  test  and  Qual  test  report  in 
most  cases. 

Review  documentation  to  ensure  that  devel  spec,  product 
draft,  drawings  and  qual  test  report  are  consistent. 

Physical  Audit 

Approve  Product  Spec. 

Approve  final  drawings 
Set  product  baseline 

ECP  required  for  future  product  baseline  changes 
PMRT  —  Participate  as  appropriate 

Small  programs  are  often  rushed  to  contract  due  to  financial  considera¬ 
tions,  give  the  illusion  of  simplicity  and  often  have  less  experienced 
project  managers.  For  any  program,  however,  it  places  CM  in  a  position 
to  influence  the  conduct  of  the  program  in  the  critical  early  phases  and 
to  make  a  positive  contribution  to  the  management  effort.  It  is  normal 
practice  for  program  management  to  turn  to  Engineering  for  performance 
support,  to  turn  to  the  Controller  for  financial  management  support,  to 


turn  to  Program  Control  and  Procurement  for  their  respective  support. 
Configuration  Management  is  in  a  position  to  contribute  a  great  deal 
more  than  administrative  and  clerical  functions.  Let  them  turn  to 
Configuration  Managers  for  Configuration  Management.  AFR  65-3  should 
reflect  this  charter. 


WILLIAM  G.  FOHRMAN,  Lt  Col,  USAF 
Director,  Configuration  6  Data  Mgmt 
Deputy  for  Acquisition  Support 
Hq,  Aeronautical  Systems  Division 
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AN  INTEGRATED  DATA  BASE  APPROACH  TO  CONFIGURATION 
MANAGEMENT  AND  TECHNICAL  DOCUMENTATION  CONTROL 

BY 

E.  W.  ANDERSON 
MARTIN  MARIETTA  CORPORATION 


SUMMARY 

This  paper  covers  the  interrelationships  of  engineering  design 
data  (parts  lists),  technical  documentation  control  and  configuration 
management  status  and  accounting,  including  change  control,  hardware 
incorporation  verification  and  schedule  data.  It  then  shows  how  Martin 
Marietta's  Technical  Requirement  Management  System  (TRMS)  used  those 
relationships  in  an  integrated  data  base  approach  to  data  management. 


INTRODUCTION  -  In  today's  environment  of  high  technology  systems 


and  products  there  is  a  need  to  know,  on  a  day-to-day  basis,  what 
the  product  is  as  it  develops  from  concept  to  delivered  item.  In 
addition,  there  are  contractural  customer  requirements  to  be  met. 
Configuration  management  disciplines  must  be  enforced  to  assure  that 
those  requirements  are  identified,  recorded  and  controlled.  The  data, 
functions  and  information  to  be  gathered,  controlled  and  disseminated 
to  management  and  customer,  have  certain  relationships  that  can  be 
used  in  an  integrated  data  base  to  maximize  processing  efficiency, 
increase  data  integrity  and  provide  the  most  useful  management  tools. 

Martin  Marietta's  Technical  Requirements  Management  System  (TRMS) 
was  developed  using  this  integrated  data  base  approach.  The  use  of 
TRMS  on  a  program  results  in  increased  productivity  and  lower  costs 
through  efficient  project,  engineering,  configuration  and  data  manage¬ 
ment. 

BACKGROUND  -  A  study  was  made  to  explore  the  feasibility  of  re¬ 
placing  existing  planning,  engineering  and  configuration  management 
computer  systems.  These  systems  could  be  represented,  as  shown  in 
Figure  I,  as  separate  programs  processing  their  own  files.  The  study 
concluded  that  75  to  80%  of  the  data  in  these  separate  files  was  re¬ 
dundant  and  that  all  the  data  was  functionally  related.  Therefore, 
the  decision  was  made  to  merge  these  separately  treated  functions  of 
design  engineering  and  configuration  management  into  a  single  data 
base  structured  system. 


N-2 


SYSTEM  DESCRIPTION  -  TRMS  is  divided  into  six  functional  in¬ 


dependently  operating  systems: 

o  Requirements  Identification 
o  Planning  and  Scheduling 
o  Document  Status 
o  Parts  Data 

o  Configuration  Verification 
o  As  Designed /As  Built 

While  each  function  can  operate  independently,  all  data  is 
stored  in  an  integrated  data  base  structure  for  access  and  use  by  any 
system.  A  graphic  representation  of  this  is  shown  in  Figure  II. 

Figures  I  and  II  vividly  depict  the  difference  possible  with  an 
integrated  data  base  approach  to  data  management. 

TYPES  OF  DATA  -  The  data  to  be  managed  can  be  grouped  into  five 
basic  categories: 

o  Configuration  Items 
o  Documents 
o  Parts 
o  Tasks 
o  Schedules 

The  information  to  be  processed  can  be  grouped  into  five  basic 
categories : 


o  Identification 
o  Planning 


o  Controlling 
o  Statusing 
o  Reporting 

The  functions  to  be  performed  require  that  the  data  to  be  stored 
and  its  related  information  be  organized  in  a  manner  such  that  each 
function  can  be  completely  independent,  yet  have  data  easily  usable 
by  all  functions.  Therefore,  a  data  base  structure  was  established 
with  an  End  Item  (C.I.)  Record,  Drawing  Record,  Part  Record  and  Task 
Record.  Each  root  data  record  segment  then  carried  its  associated 
reference  data  with  it.  Where  a  data  element  appears  more  than  once, 
it  is  the  same  element. 

RELATIONSHIPS  -  Configurations  or  end  items  are  controlled  by  a 
part  number  and  serial  number. 

A  part,  assembly  or  subassembly  is  defined  by  a  part  number 
and/or  revision  level. 

A  drawing  is  controlled  by  a  number  and  a  revision  level. 

A  change  to  a  drawing  is  controlled  by  a  task. 

Planning  defines  schedule  dates  and  change  incorporation  points. 
Control  is  established  by  verification  of  data  and  interlocking 
related  data  as  each  design  or  build  function  is  verified. 

Based  on  the  data  in  the  data  base,  reports  can  then  be  prepared 
giving  status  and  other  information  required  for  the  program  manage- 


FUNCTIONAL  DESCRIPTIONS 


REQUIREMENTS  IDENTIFICATION  -  Identifies  the  design  and/or  build 
requirements.  End  items  (or  configuration  items)  are  defined  by  number, 
drawinq,  part  number,  serial  number  and  description.  The  C.I.  can  also 
be  allocated  to  usage,  build  location,  etc. 

This  information  is  then  used  to  prepare  design  and  build  lists. 

The  file  is  then  also  used  as  a  reference  for  control  of  data  in  other 
functional  areas.  For  example,  a  drawing  or  parts  list  cannot  be  re¬ 
leased  that  is  beyond  the  authorized  scope  entered  into  the  requirements 
data  file. 

PLANNING  AND  SCHEDULING  (Task  Identification)  -  In  order  to  plan 
and  control  design  effort,  as  well  as  account  for  changes,  each  effort 
is  assigned  a  task  number  for  tracking  and  statusing. 

The  schedule  statusing  function  defines  the  work  to  be  accomplished, 
provides  milestones/events  to  be  tracked  and  authorizes  engineering 
release  activity. 

DOCUMENT  STATUS  -  This  function  defines  the  engineering  drawing, 
contract  specifications  and  any  other  program  documents  that  require 
formal  revision  control.  It  shows, revision  levels  and  authorizing 
change  authority.  It  performs  the  engineerinq  release  function  to 
control  all  data  in  the  data  base. 

PARTS  DATA  -  Provides  product  definition.  Individual  drawing 
parts  lists  are  entered  into  the  data  base.  These  lists  then  can  be 
released  as  machine  prepared  integral  parts  lists  or  separate  parts 
lists  as  required  by  contract. 
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By  making  use  of  the  individual  parts  lists,  as  contained  in  the 
data  base,  complete  product  definitions  that  require  indentured  parts 
lists,  alphanumeric  parts  lists,  where  used  lists,  etc.,  can  all  be 
prepared  by  the  computer. 

The  parts  data  base  also  then  can  prepare  the  as  designed  list  to 
be  used  for  as  designed/as  built  verification 

CONFIGURATION  VERIFICATION  -  Using  data  already  entered  into  the 
data  base,  baseline  configurations  can  be  established.  Changes  can  be 
scheduled  and  incorporation  points  planned  to  provide  configuration 
status  and  accounting  reports. 

INTEGRATED  DATA  BASE  -  The  integrated  data  base  approach  to  per¬ 
forming  the  control  and  statusing  functions  required  by  engineering  and 
configuration  management  and  the  elimination  of  data  redundancy  results 
in  the  following: 

o  Greater  Data  Integrity 
o  Broad  Reporting  Options 
o  Simplified  Data  Manipulation 
o  Minimized  Repetitive  Input 
o  Substantial  Labor  Savings 

The  single  data  base  and  simplified  processing  of  data  makes  it 
feasible  to  provide  on-line  access  and  processing  for  most  of  the  in¬ 
formation,  making  data  available  on  a  real-time  basis  to  user,  management 
and  the  customer. 


SYSTEM  USE  -  The  complete  capability  of  TRMS  allows  it  to  be  used 
in  all  phases  of  a  program  from  RFP  to  hardware  delivery. 

When  an  RFP  is  received,  a  schedule  for  proposal  preparation  and 
submittal  can  be  entered  and  statused. 

As  hardware  requirements  are  identified,  they  are  entered  into  the 
data  base.  Advance  parts  lists,  drawing  trees,  CFE,  GFE  lists,  etc., 
can  be  prepared.  These  lists  and  associated  data  can  be  used  as  part 
of  the  proposal,  as  well  as  for  backup  data. 

The  data  once  entered  is  stored  and  used  as  required  during  follow¬ 
ing  program  phases  and  need  not  be  reinput. 

Product  definition,  from  C.I.  identifier  to  parts  lists,  drawing 
control  and  change  identification,  is  entered  into  the  system.  Change 
incorporation  verification  is  added  to  the  system  as  it  occurs. 

At  product  completion,  reports  are  prepared  that  show  C.I.  con¬ 
figuration  by  as  designed/as  built  lists  with  change  accountability  and 
verification  for  customer  buy-off. 

CONCLUSION  -  Since  all  functional  data  for  design  and  build  require 
ments,  parts  lists,  change  definition,  schedule  status  and  configuration 
verification  are  in  a  common  on-line  data  base,  accessible  on  a  real¬ 
time  basis,  complete  and  up-to-date  information  is  available  during  all 
phases  of  a  program.  Martin  Marietta's  TRMS  is  an  up  and  operating 
system  making  use  of  this  concept  to  provide  its  management  with  the 
tools  needed  for  efficient  program  control. 
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INDVIOUAL,  SINGLE-FUNCTION  SYSTEMS 
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FUNCTIONAL  SYSTEMS 

•  REQUIREMENTS  IDENTIFICATION 
•  PLANNING  AND  SCHEDULING 
•  DOCUMENT  STATUS 
•  PARTS  DATA 

•  CONFIGURATION  VERIFICATION 


•  AS  DESIGNED/AS  BUILT 


INFORMATION 

•  IDENTIFICATION 
•  PLANNING 

•  CONTROLLING 
•  STATUSING 


•  REPORTING 


ADVANTAGES 


•  GREATER  DATA  INTEGRITY 

•  BROADER  REPORTING  OPTIONS 

•  SIMPLIFIED  DATA  MANIPULATION 
•  MINIMIZED  REPETITIVE  INPUT 

•  SUBSTANTIAL  LABOR  SAVINGS 


US  ROLAND 

INTERNATIONAL  INTERCHANGEABILITY 


i  BACKGROUND 

-  INITIAL  CONTRACT  WITH  HUGHES  HAD 
NO  REQUIREMENT  FOR  INTERNATIONAL 
INTERCHANGEABILITY 

-  US-EUROPEAN  JOINT  EFFORTS  INITIATED 
TO  MINIMIZE  SYSTEM  DESIGN  DIFFERENCES 

-  CONTRACT  MODIFIED  TO  REQUIRE  US- 
EUROPEAN  MISSILE  INTERCHANGEABILITY 

-  US-EUROPEANS  AGREE  TO  CONSIDER  AN 
EXPANDED  LIST  OF  558  ITEMS  FOR  |2 


CONFIGURATION  MANAGEMENT 
OBJECTIVES 


MAXIMIZE  INTERCHANGEABILITY 
LATEST  POSSIBLE  EUROPEAN  DESIGN  IN  TTF&T 
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ALL  TTF&T  HARDWARE  IDENTICAL 
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ROLAND  POLICY  ON  METRICS 
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METRIC  DIMENSIONS  TRANSFERRED 
DIRECTLY  TO  US  DRAWINGS 

NEW  DESIGNED  ITEMS  FOR  SYSTEM 
TO  BE  IN  METRICS 

NO  DUAL  DIMENSIONS  ALLOWED  ON 
DRAWINGS 
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CONFIGURATION  REVIEW 
GROUP  (CRG) 


•  OBJECTIVE 

-  TO  ESTABLISH  AN  OPTIMUM  LEVEL  OF  INTER¬ 
CHANGEABILITY  BETWEEN  THE  US  AND  EUROPEAN 
ROLAND  SYSTEMS 

-  PROVIDE  MECHANISMS  FOR  MAINTAINING  I2  AT 
THIS  LEVEL 

•  RESPONSIBILITY 

-  IDENTIFY  AND  RESOLVE  DIFFERENCES  IN  REQUIRE¬ 
MENTS  AND  MATERIEL  DEFINITION 

•  FUNCTIONS 

-  RESOLVE  Dl  FFERENCES  TO  MAXIMUM  EXTENT 
POSSIBLE  BETWEEN  SYSTEMS 

-  REFER  ACTIONS  TO  JRCC 
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US/EUROPEAN  MEMORANDUM  OF  UNDERSTATING 
(MOU)  STATEMENT  OF  INTERCHANGEABILITY 


"THE  PARTICIPATING  COUNTRIES  AGREE  IN  THE 
INTEREST  OF  INTERNATIONAL  STANDARDIZATION 
OF  MILITARY  EQUIPMENT,  TO  MAINTAIN  A  DESIGN 
WHICH  WILL  PROMOTE  INTERCHANGEABILITY  OF 
SYSTEM  COMPONENTS  MANUFACTURED  BY  THE 
PARTICIPATING  COUNTRIES.  THE  OBJECTIVE  IS 
TO  BE  ACHIEVED  BY  KEEPING  INTERCHANGE- 
ABILITY  TO  THE  MAXIMUM  EXTENT  FEASIBLE 
CONSISTENT  WITH  NATIONAL  PREROGATIVES." 
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DEFINITION  OF  INTERNATIONAL 
INTERCHANGEABILITY 


Holanb 


AN  ITEM  IS  INTERNATIONALLY  INTERCHANGEABLE 
IF  IT  IS  EXCHANGEABLE  IN  FORM,  FIT  AND  FUNCTION 
AND  RETAINS  THE  SAME  PERFORMANCE  IT  ORIGINALLY 
HAD.  VARIATIONS  IN  SAFETY,  RELIABILITY,  MAIN¬ 
TAINABILITY,  AND  OTHER  SIMILAR  TRAITS  MAY 
CHANGE,  HOWEVER. 
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STATUS  OF  TirTERNATIONAL  IfflRftCUANGFAMLm  (r)  CANDHYlTE  LIST 
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The  US  ROLAND  Program  is  new  realizing  maximini  benefit  of  standardizing  hardware  with  our 
European  allies.  For  example,  the  l.OLAND  Missile  is  ca.'pletely  interchangeable  between  the 
three  countries  involved.  This  interchangeability  will  enable  the  French  and  Germans  to  fire  a 
US  missile  from  a  European  launcher  and  vise  versa.  To  further  illustrate  tlie  degree  of  system 
hardware  interchangeability,  approximately  967.  of  Field  Replaceable  Units  (I'RU)  (slightly  more 
than  600)  in  the  transferred  European  ROLAND  design  (i.e.,  the  total  ROLAND  System  less  European 
national  items)  are  interchangeable. . 
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STATUS  OF  INTERNATIONAL 
INTERCHANGEABILITY  (I2)  CANDIDATE  LIST 
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SUMMARY 


TECHNOLOGY  TRANSFER  SUCCESSFULLY  COMPLETED 

-  25,000  DOCUMENTS  COMPRISE  "DEFINITION  FILE" 

-  76,000  ADDITIONAL  DOCUMENTS  CONVERTED 

-  4.2  MILLION  TECHNICAL  DOCUMENT  WORDS 
TRANSLATED 

-  90%  EXACT  EQUIVALENT  PARTS 

-  92%  EXACT  EQUIVALENT  MATERIALS  AND  PROCESSES 

-  FIRST  ANGLE  PROJECTION  AND  METRIC  DRAWING  USE 
SUCCESSFULLY  DEMONSTRATED 

CONTROL  AND  DISPOSITION  OF  EUROPEAN  AND  US  CHANGES 
POSITIVELY  ESTABLISHED 

VIABLE  ORGANIZATION  ESTABLISHED  TO  MAXIMIZE 
STANDARDIZATION  AND  INTERNATIONAL  INTERCHANGEABILITY 

U2> 

OVER  600  CANDIDATE  I2  ITEMS 

DESIGN  AND  REQUIREMENT  DIFFERENCES  MINIMIZED 

PLANS  ESTABLISHED  BETWEEN  US  AND  EUROPEAN  PARTNERS 
FOR  MAINTAINING  MAXIMUM  I2 
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LESSONS  LEARNED 
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•  OBTAIN  ENOUGH  DATA  TO  UNDERSTAND  COMPLEXITY 
OF  TECHNICAL  DATA  TRANSFER 

•  PROPOSALS  SHOULD  ADEQUATELY  ADDRESS  COST  AND 
SCHEDULE  TO  COMPLETE  TRANSFER 

•  SYSTEMS  DESIGN  STABILITY  MUST  BE  ASSESSED 

•  ORGANIZATION  MUST  BE  ESTABLISHED  TO  REQUIRE 
CLOSE  COORDINATION  WITH  US  AND  FOREIGN  CONTRACTOR 
AND  GOVERNMENT  ORGANIZATIONS 

•  PM  MUST  MAKE  FREQUENT  PERSONAL  VISITS  TO  HIGH  LEVEL 
US  AND  EUROPEAN  GOVERNMENT  AND  CONTRACTOR 
PERSONNEL 

•  PROGRAM  INTERFACES  MUST  BE  ESTABLISHED  EARLY  TO 
ALLOW  TECHNOLOGY  TO  BE  TRANSFERRED  IN  ORDERLY 
MANNER 
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Vanishing  Frontiers  of  Technology  Boosts 
Digitization  of  Engineering  Data 

S.  L.  Simmons 
Head,  Configuration  Division 
Naval  Ship  Weapon 
Systems  Engineering  Station 
Port  Hueneme,  California  93043 

This  paper  briefly  addresses  the  current  state  of  computer-aided  design  technology 
and  automated  production  techniques  and  points  out  some  considerations  and  facts  that 
would  aid  interested  organizations  in  attaining  solutions  to  the  problem  of  storing, 
manipulating  and  outputting  data  usable  by  man  and  machine. 

Attaining  this  goal  will  ultimately  provide  users  with  a  universally-applicable  digital 
system  that  will  increase  productivity  and  cost  savings.  It  is  for  this  reason  additional  or¬ 
ganizations  are  encouraged  to  participate  in  breaking  down  the  last  few  frontiers. 


It  is  a  pleasure  for  me  to  be 
here  to  talk  to  you  about  “how”  vanish¬ 
ing  frontiers  of  technology  boost  digitiza¬ 
tion  of  engineering  data.  Digitization  as 
used  here  means  conversion  of  information 
into  a  binary  representation. 

This  is  an  area  of  vital  concern 
to  us  at  the  Naval  Ship  Weapon  Systems 
Engineering  Station  and  to  the  Surface 
Warfare  Fleet.  Because  of  this,  I  want  to 
take  a  few  moments  to  review  the  begin¬ 
ning  of  the  Naval  Ship  Weapon  Systems 
Engineering  Station.  more  commonly 
known  as  “NEMESIS”,  and  to  discuss  its 
mission  so  as  to  set  everybody’s  feet  on 
the  ground  regarding  the  “Why”  of  our 
real  interest  in  digitization  of  engineering 
data.  The  Engineering  Station  traces  its 
origin  to  the  closing  days  of  World  War 
II.  Although  U.S.  Naval  gunfire  was  fair¬ 
ly  effective  in  warding  off  Japanese  Kami¬ 
kaze  attacks,  the  attacks  demonstrated 
clearly  that  a  need  existed  for  more  effec¬ 
tive  weapon  systems.  Consequently,  the 
Navy  embarked  on  an  accelerated  pro¬ 
gram  in  the  late  40 's  and  early  50 ’s  to 
develop  what  became  known  as  the  Talos. 


Tartar  and  Terrier  surface-to-air  guided 
missiles.  The  development  of  these  mis¬ 
siles  -  we  call  them  the  Three  T’s  -  creat¬ 
ed  the  additional  requirement  for  a  single 
Navy  activity  dedicated  to  the  support  of 
these  complex  systems.  As  a  result  of 
this  need,  the  Naval  Ship  Missile  Systems 
Engineering  Station  was  activated  as  a 
tenant  activity  on  the  Seabee  Base  at  Port 
Hueneme.  The  verbal  acronym 
“NEMESIS”  came  into  usage  at  that 
time.  There  were  many  reasons  for 
selecting  the  construction  battalion  center 
as  the  host  for  our  unique  organization. 
The  principal  ones  were  the  availability  of 
a  deep  water  port  (the  only  one  between 
Los  Angeles  and  San  Francisco),  the 
proximity  of  the  Pacific  Missile  Test 
Range,  availability  of  existing  facilities  at 
the  Seabee  Center,  and  the  bonus  of  a 
good  labor  market  in  the  surrounding 
communities. 

On  8  July  1963.  the  Station  was 
commissioned  with  a  cadre  composed  of 
58  contractors,  civilian  employees  and 
military  personnel.  Since  then,  the 
Station’s  tasks  and  personnel  allowances 
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have  continued  to  grow.  This  growth  led, 
in  1972.  to  a  name  change.  The  Station 
initially  was  responsible  for  surface  missile 
systems.  Today  it  is  involved  with  gun 
lire  control  systems,  surface  weapons 
switchboards,  some  search  radars,  under¬ 
way  replenishment  and  new  systems  such 
as  AEGIS  and  HARPOON.  Accordingly, 
the  word  "missile’*  was  dropped  in  favor 
of  "weapon”.  The  verbal  acronym  - 
NEMESIS  -  remained  the  same,  however. 

Today  our  work  force  is  com¬ 
posed  of  nearly  1700  civilian  and  about 
75  military  personnel.  Our  main  thrust  at 
the  Station  is  in-service  engineering.  Sim¬ 
ply  stated,  that  means  fleet  support  - 
make  it  work  and  keep  it  working.  To 
accomplish  this  task.  38  percent  of  our 
work  force  is  composed  of  professional 
engineers  and  another  17  percent  of  elec¬ 
tronic  and  engineering  technicians.  Anoth¬ 
er  33  percent  represents  such  professional 
disciplines  as  quality  assurance,  personnel 
and  computer  specialists,  management  and 
program  analysts,  logistics  specialists,  ac¬ 
countants.  budget  specialists  and  math¬ 
ematicians. 

When  NEMESIS  was  organized 
in  1963.  there  were  only  50  ships 
equipped  with  missile  systems.  Its  mission 
then  was  to  improve  the  performance  of 
the  Three  T's.  Now.  in  the  late  seven¬ 
ties.  the  Station  provides  engineering  and 
logistics  support  to  more  than  200  surface 
combatant  and  auxiliary  ships  throughout 
the  world  The  command  also  provides 
support  for  37  ships  of  nine  friendly  fo¬ 
reign  nations.  Our  parent  command,  the 
Naval  Sea  Systems  Command,  further  ex¬ 
panded  our  mission  by  designating 
NEMESIS  as  a  Navy  test  and  evaluation 
activity  tor  surface  weapon  systems. 

I  his  growth  in  the  number  of 
ships  supported  and  the  types  of  support 
required  has  been  accompanied  bv  an  in¬ 
crease  in  the  technical  data  ( parts  lists. 


engineering  drawings,  specifications,  design 
data,  etc.)  that  the  Station  has  to  prepare, 
update,  distribute,  store,  and  maintain  cur¬ 
rent. 

The  Station’s  technical  data 
department  provides  the  centralized  loca¬ 
tion  for  the  unique  storage,  updating,  and 
retrieval  capability  of  this  data.  The 
work  effort  is  large  and  it  is  going  to  get 
larger. 

These  greatly  expanded  responsi¬ 
bilities.  along  with  the  growing  technical 
complexity  of  surface  systems,  have  made 
the  task  of  technical  data  management 
and  configuration  management  even  more 
essential  than  it  was  in  1963  when  the 
Station  was  commissioned.  To  meet  the 
future  requirements  for  accurate  and  time¬ 
ly  technical  data  support,  the  Station  must 
seek  new  and  improved  techniques  to 
store,  update  and  retrieve  technical  data. 

During  a  typical  year,  we  process 
1200  engineering  change  proposals  and 
167  final  Ordnance  Alteration  (ORDALT) 
texts.  We  review  the  data  defining  more 
than  a  quarter  million  hardware  line 
items.  The  data  repository  that  supports 
this  activity  is  a  three  million  aperture 
card  library.  Approximately  1/3  of  a  mil¬ 
lion  aperture  cards  are  entered  into  this 
file  each  year  as  new  weapon  systems  are 
incorporated  into  the  fleet  and  old  systems 
are  updated. 

It  is  apparent  to  the  technical 
data  community  at  NEMESIS  that  new 
technology  is  moving  into  the  area  of 
automated  production  of  engineering 
drawings.  Throughout  industry,  company 
after  company  has  "married"  configura¬ 
tion  and  data  management  systems.  A 
primary  objective  at  NEMESIS  is  to  capi¬ 
talize  on  the  industrial  community's  ex¬ 
perience  in  fully  automating  the  produc¬ 
tion.  storage,  retrieval  and  integration  cy¬ 
cles  of  engineering  drawings  and  related 


Uses  and  specifications  and  move  forward 
to  an  era  wherein  all  engineering  data  is 
digitized. 

To  assess  this  developing  situa¬ 
tion,  NEMESIS  sponsored  master’s  theses 
of  two  Naval  Postgraduate  School  stu¬ 
dents,  Lieutenant  Commander  Billie  Wie- 
land  and  Lieutenant  John  Pounds,  both 
now  graduated.  Professor  Peter  C.  Wang 
coordinated  their  efforts  here  at  Monterey. 
Linder  his  guidance,  the  students  had,  as 
their  specific  objective,  the  development  of 
a  plan  for  upgrading  the  equipments  and 
techniques  at  NEMESIS  to  meet  the  needs 
of  the  I980’s. 

Among  other  things,  these  studies 
confirmed  not  only  that  industry  is  indeed 
converting  to  automated  or  semi-automat¬ 
ed  drafting  and  interactive  design  systems, 
but  that  industry  was  rapidly  moving  into 
the  era  of  computer  aided  manufacturing. 
The  day  when  the  theories  and  practice 
of  design  and  manufacturing  would  be 
tightly  interlocked  and  interwoven  ap¬ 
peared  to  be  just  a  few  years  ahead. 
However,  the  utilization  of  digitized  engi¬ 
neering  data  on  a  scale  to  support  an  ac¬ 
tive  library  of  three  million  aperture  cards 
seemed  to  be  neither  efficient  or  effective 
at  the  time  this  study  was  made.  Major 
problems  in  the  technology  for  storage, 
presentation  and  transmission  of  data  miti¬ 
gated  against  digitization. 

Since  that  report,  the  driving 
force,  industry’s  continued  expansion  of 
computer  technology,  has  continued  at  an 
increasing  rate. 

Today  there  are  digitally  driven 
equipments  such  as  color  TV  displays, 
high  speed  printers,  and  microfile  devices 
that  are  used  to  assist  designers  in  the 
development  of  a  long  list  of  products. 
Use  of  computers  with  these  output  de¬ 
vices  present  to  designers  as  never  before 
an  opportunity  to  visualize  design  and 


check  performance  changes.  General  Mo¬ 
tors  Corp.  has  advertised  on  television  and 
in  weekly  magazines  the  use  of  these 
techniques  in  developing  their  automotive 
products.  However,  they  are  far  from  be¬ 
ing  the  only  ones  in  this  field.  Designers 
use  colored  TV  to  view  fabric  patterns, 
color  schemes,  three-dimension  projections 
of  castings  and  machined  parts,  micro  cir¬ 
cuit  layouts,  logical  designs,  system  flow 
networks  for  industrial  plants,  chemical 
production  and  traffic  systems  among 
many  others.  Today’s  designer  uses  the 
digits  flowing  through  computers,  transmis¬ 
sion  systems,  and  all  types  of  display  de¬ 
vices  to  implement  their  visualizations  of 
design  criteria  needed  to  meet  the  pro¬ 
duction  demands  of  industry. 

After  products  are  designed,  other 
engineers  again  turn  to  the  same  sets  of 
digital  equipment  to  aid  in  the  manufac¬ 
ture  of  products.  Working  with  this  tech¬ 
nology,  they  develop  programs  to  control 
a  wide  range  of  production  equipment. 
The  variety  of  these  equipments  and  field 
of  use  expands  daily.  Digital  control  of 
weaving  machinery  is  more  than  a  century 
old.  Numerically  controlled  machine  tools 
have  been  around  for  several  decades. 
Computer  controlled  wire  wrapping  has 
been  used  for  more  than  a  decade.  Now 
we  have  laser  beams  under  computer  con¬ 
trol  cutting  out  patterns  for  clothing.  To 
accommodate  the  demand  for  smaller  and 
smaller  circuitry,  computers  control  laser 
beams  and  x-ray  to  form  the  latest  in 
micro-circuitry.  Today  many  companies 
have  bridged  the  gap  between  computer 
aided  design  and  computer  aided 
manufacture  to  the  extent  that  engineering 
drawings  as  we  now  know  them  are  not 
needed.  The  driving  force  of  automation 
is  replacing  the  draftsman  and  his 
product,  except  where  company  and/or 
government  contracts  backed-up  by  regula¬ 
tions  and  standards  require  conventional 
drawings.  Recently,  I  talked  to  an  engi¬ 
neer  from  one  of  the  nations  more  aggres- 


I 
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sivclv  innovative  companies.  Thev  design, 
build  and  test  parts  without  engineering 
drawings  and  then  turn  the  completed 
parts  over  to  a  team  of  draftsmen  so  that 
regulations  and  standards  can  be  met. 
I'he  need  exist*,  now  and  is  growing 
dramatically  for  new  methods  of  storing, 
retrieving,  transmitting  and  presenting  en¬ 
gineering  data. 

Although  the  technology  of  sever¬ 
al  years  ago  seemed  inadequate  to  support 
a  general  across  the  board  digitization  of 
engineering  data,  new  products  are  closing 
the  gap  between  the  visionary  schemes  of 
yesterday  and  the  realities  of  today. 

In  fact  there  have  been  across 
the  board  reductions  in  cost  and  size  of 
the  equipment  coupled  with  increased 
speed  of  operation  and  computational 
power.  Of  course,  this  could  have  been 
expected  as  graphs  of  the  period  from 
1965  to  I  s)7 indicated  this  would  hap¬ 
pen 

Observing  the  available  data,  hi 
1959.  there  was  one  component  per  circuit 
while  there  were  about  32  thousand  com¬ 
ponents  in  1075.  lodav  there  are  equip¬ 
ments  in  use  with  more  than  262  thou¬ 
sand  components  per  circuit.  Looking  at 
the  speed  of  switching  units  we  find  that 
in  1959  we  had  available  some  mi- 
crosecond  units  while  today  the  industry  is 
building  nanosecond  switching  units. 
Looking  into  costs  we  find  that  although 
the  value  ol  the  dollar  has  been  decreas¬ 
ing.  the  price  of  digital  circuitry  keeps  de¬ 
creasing  \s  .m  example,  the  cost  of  IK 
bytes  ot  computer  memory  was  about 
532ifOO  m  |97t  ,md  u  costs  ,i>  little  as 
532  00  today  for  a  smaller  and  faster  unit. 
In  the  field  of  mass  memories,  since  197(1 
we  have  been  at  a  plateau  of  n.250  bytes 
per  inch  for  magnetic  tapes  used  in  the 
general  trade  Now  new  technology  will 
support  a  quantum  |ump  io  65.000  bytes 
per  inch  ol  tape  Suddenly  a  tape  library 


can  be  ten  times  smaller.  But  increasing 
density  is  not  limited  to  magnetic  tapes, 
disc  memory  density  is  also  increasing. 
The  latest  releases  indicate  an  increase 
from  29  million  bytes  per  disc  pack  in  the 
1969  era  to  635  million  bytes  of  data  per 
pack  in  1979.  Then  in  the  area  of  mass 
storage,  the  latest  releases  claim  a  max¬ 
imum  acquisition  time  of  5-1/2  seconds 
with  a  total  storage  capacity  of  152  bil¬ 
lion  bytes.  This  equipment  does  not  yet 
use  the  latest  in  high  density  tape  storage, 
therefore  even  this  system  is  subject  to 
further  expansion  within  the  bounds  of 
known  technology.  Several  other  mass 
storage  devices  are  coming  on-line.  One 
is  Bubble  memory  technology.  This  is  a 
relatively  new  technology  but  one  already 
finding  a  secure  niche  in  the  communica¬ 
tions  industry.  Even  here,  new  technology 
alreadv  tested  will  allow  4  million  bits  to 
be  stored  in  a  I -CM2  chip.  At  the  same 
time,  the  new  techniques  will  permit  a 
speed  increase  of  not  less  than  10  times 
the  speed  of  presently  available  units. 
And  further,  experts  in  this  field  expect 
equally  significant  product  improvements 
in  the  near  future.  The  other  technology 
that  has  arrived  is  video  disc.  This  is  not 
a  new  field,  but  what  has  happened  is 
significant.  Video  discs  are  being  built 
tor  the  home  entertainment  market.  The 
costs  for  encoding  and  decoding  technolo¬ 
gy  has  been  reduced  by  a  magnitude 
when  compared  with  test  units  of  just 
four  years  ago. 

In  the  field  of  conversion  of 
graphics  to  digits,  the  most  significant  for¬ 
ward  steps  have  been  made  in  the  field 
of  scanning.  Solid  state  devices  such  as 
the  Linear  Array  Charged  Coupled  Scan¬ 
ning  elements  immediately  convert  an  im¬ 
age  directly  into  digital  signals.  These  de¬ 
vices  have  greatly  simplified  conversion 
techniques  while  reducing  costs.  But  more 
conventional  scanning  techniques  have  also 
shown  dramatic  speed  increases  with  ove¬ 
rall  cutting  of  operational  costs.  Parallel 


with  development  of  better  scanning  de¬ 
vices.  the  video  display  field  is  expanding 
rapidly.  105  megahertz  bandwidths  for  a 
Cathode  Ray  Tube  is  becoming  common¬ 
place.  In  another  Cathode  Ray  Tube 
area,  one  manufacturer  offers  a  desk  top 
computer  with  high  density  19"  storage 
display.  This  unit  has  excellent  capabili¬ 
ties  to  present  engineering  data  to  a  user 
who  desires  to  scan,  and  possibly  update 
it. 

One  last  area  where  improve¬ 
ments  impact  digitization  of  engineering 
data  is  communications.  Costs  for  receive 
sites  for  satellite  communications  have 
come  down  significantly.  Today  a  receive 
only  site  can  be  installed  for  as  little  as 
$25,000.00.  This  is  but  a  small  item  of 
the  total  picture.  However,  indicative  of 
the  tremendous  acceleration  in  the  field  of 
communications.  AM  International  will  of¬ 
fer  to  industry  in  1981  a  facsimile  system 
able  to  transmit  one  page  every  second. 
The  system  will  require  a  1-1/2  megahertz 
bandwidth.  This  technology  can  be  readi¬ 
ly  used  to  transmit  engineering  data. 
Since  engineering  data  is  a  valuable  form 
of  information,  it  is  apparent  that  this 
technology  will  be  used  to  transmit  techni¬ 
cal  data. 

A  review  of  technology  available 
now  and  four  years  ago  confirms  that 
graphical  charts  showing  decreasing  costs 
and  increasing  capabilities  for  digital 
equipments  in  the  future  are  still  on  track. 

The  question  that  must  be  faced 
today  is  this:  "Has  the  driving  force  of 
industry  use  of  CAD/CAM  brought  the 
data  world  to  the  point  where  digital  stor¬ 
age.  retrieval  and  transmission  of  engi¬ 
neering  data  will  be  implemented?” 
Some  companies  and  a  few  government 
agencies  believe  that  it  has. 


1  will  mention  three  activities. 
The  first  is  PRC  Image  Data  Systems  of 
McLean,  Virginia.  Dr.  Gerad  Walter  of 
their  company  has  written  several  articles 
about  this  subject  and  has  proposed  what 
he  calls  the  Total  Information  Environ¬ 
ment.  The  second.  Defense  Logistics  Ser¬ 
vices  Center  of  Battle  Creek,  Michigan,  is 
installing  a  system  for  digitization,  storage 
and  retrieval  of  engineering  data.  And 
the  third  is  the  U.S.  Army  Research  and 
Development  Command  at  the  Aberdeen 
Proving  Ground,  Maryland.  At  that  ac¬ 
tivity  they  are  installing  a  system  that  will 
digitize,  store  and  retrieve  engineering 
data. 

As  never  before  there  is  an  inter¬ 
national  race  for  technical  supremacy,  it 
may  be  even  a  race  for  survival  of  the 
world  as  a  dynamic  entity.  At  this  junc¬ 
ture  of  events,  we  are  approaching  the  era 
of  total  digitization  of  the  medias  of  in¬ 
formation.  speech,  printed  material,  and 
graphics.  The  driving  force  of  change  is 
going  to  impact  the  field  of  engineering 
data.  Moveable  type  revolutionized  print¬ 
ing  and  brought  about  a  great  diffusion 
of  knowledge  throughout  civilization.  To¬ 
day  thcJ'simplest  of  information  forms,  the 
binary  element,  as  used  in  manufacturing, 
communications  and  problem  solving,  is 
producing  another  revolution  of  informa¬ 
tion  flow  unparalleled  in  all  history.  The 
frontiers  of  digital  technology  as  outlined 
above  are  being  pushed  back  at  a  tremen¬ 
dous  pace. 

Every  data  manager  will  soon 
have  to  prepare  for  the  coming  of  digiti¬ 
zation.  Let  us  trust  that  none  of  us  will 
be  “a  day  late  and  a  dollar  short”  in 
meeting  the  coming  age  of  a  total  Digital 
Information  Ensironment. 
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June  4,  1979 


ADPA  Technical  Documentation  Division 
Data  Management  Section  Workshop 

Workshop  Chairman  introduced  Mr.  Vince  Mayolo,  DMSSO,  and  Mr.  Harvey 
Cook,  Northrop,  as  a  select  panel  with  Mr.  Bud  McCarty  as  Recorder,  to 
focus  comments  and  replies  to  topics/questions  identified  by  workshop 
participants.  Included  in  the  group  were  twenty-two  (22)  from 
Government  organizations,  twenty-one  (21)  from  Industry,  and  one  (1) 
unattached.  Fourteen  (14)  questions  (many  multi-part)  were  submitted 
by  eleven  (11)  participants,  and  are  summarized  below. 

Question  1  -  Are  there  definitions  that  provide  enough  information  to 
delineate  the  difference  between  data  management  and  configuration 
management? 

Response  1  -  Some  reported  combination  of  these  functions  in  one 
organization;  some  feel  this  combination  tends  to  weaken  each 
function;  some  feel  that  Data  Management  is  essentially  the 
configuration  management  of  data.  It  was  agreed  that  there  is 
widespread  misunderstanding  of  what  the  data  management  discipline 
actually  is  (or  should  be)  both  in  Government  and  Industry. 

Question  2  -  What  is  the  status  of  DOD  5000. 32M?  What  were  the  main 
Government  comments?  What  were  the  main  Industry  comments?  What 
are  the  future  plans  for  this  document? 

Response  2  -  provided  by  Mr.  Mayolo  -  For  all  practical  purposes,  this 
document  is  dead;  although  the  philosophy/ policy  contained  therein 
is  very  much  alive.  Comments  from  the  three-services  were  good, 
with  those  from  two  services  constructive  -  the  third  service 
essentially  wanted  no  change  in  status  quo.  Although  Mr.  Golmis's 
report  had  mentioned  substantial  ADPA  coordination  on  this  draft 
document,  no  official  ADPA  comments  were  received.  The  CODSIA 
comments  were  reviewed  briefly  by  Mr.  Mayolo,  who  also  noted  some 
concern  in  apparent  CODSIA  review  procedures.  It  was  indicated 
that  the  essentials  of  DOD5000.32M  would  probably  be  coming  out 
under  another  number. 

Questions  3,  4,  5  -  Several  questions  on  data  pricing:  Are  there  any 
established  methods  for  cost  estimating  data?  How  is  estimating 
done  by  other  contractors?  Contractor  price  grouping  of  data 
items  is  a  dilemma.  Examples  provided  by  DD1423  etc.  are  not 
clear.  Could  the  Government  suggest  price  groups  for  concurrence 
by  the  contractor?  To  satisfy  the  Government  need  for  reliable 
data  costs,  can  contractors  break  out  data  preparation  costs  or 
preparation  plus  engineering  effort? 


Response*  3,  4,  5  -  The  CDRL  form  is  an  unsatisfactory  guide  for  data 
pricing.  A  more  thorough  treatise  is  contained  in  ASPM  #1.  Many 
feel  that  emphasis  should  be  on  the  element  of  delta  cost  -  and 
that  delta  costs  are  seldom  identified  to  enable  the  Government  to 
make  a  cost-benefit  decision.  It  became  evident  that  the  matter 
of  definition  of  "data"  is  essential  for  this  problem  to  be 
properly  faced  and  that  this  topic  should  be  dealt  vith  in  any 
effort  defining  the  data  management  function. 

Question  6  -  Is  there  a  spec  or  std  covering  data  and  CDRL  items 
similar  to  MIL-STD-100  for  drawing  practices? 

Response  6  -  Not  specifically  although  the  AMSDL  does  provide  some 
assistance.  This  discussion  triggered  a  major  discussion  on  the 
circumstances  surrounding  the  lack  of  a  data  management  standard. 

Question  7,  8  -  Is  the  generation  of  a  DM  std  being  seriously 
discussed?  What  happened  to  the  draft  std  on  Data  Mgt.? 

Response  7,  8  -  A  couple  of  very  preliminary  drafts  were  circulated 
last  year  with  essentially  two  responses:  (a)  violent 
disagreement  with  the  concept  by  many  in  industry  (not  associated 
in  the  day-to-day  DM  function)  and  an  official  letter  from  ALA  to 
the  workshop  chairman  and  (b>  positive  comments.  There  is  no 
current  effort  being  expended  on  this.  After  much  discussion  it 
was  Che  consensus  that  a  sub-committee  should  continue  work  in 
this  area. 

Question  9  -  ASPR  requires  the  inclusion  of  DD  Form  1660,  Mgt.  System 
List,  in  contracts.  Is  there  any  practical  value  to  this?  Does 
this  inpact  the  contractor  in  any  way?  Should  the  form  be 
rescinded? 

Response  9  -  It  is  dead  but  not  buried.  It  serves  no  current  useful 
purpose.  Recommended  that  ADPA  recommend  it's  elimination. 

Question  10  -  Why  is  the  DID  system  necessary  (paraphrase)? 

Response  10  -  History  of  events  bringing  about  creation  of  DOD  Data 
Mgt  System  was  related. 

Question  11  -  What  can  be  done  to  reduce/el iminate  the  costly  practice 
of  delivering  data  via  DD  Form  230? 

Response  11  -  A  subcommittee  has  been  established  to  assemble  adequate 
information  to  form  the  basis  for  an  ADPA  letter  to  the  FAR(DAR) 
Committee. 

Question  12  -  Discuss  DD  Form  708.  Why  use  for  data  in  lieu  of  DD 
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Response  12  -  Developed  by  AFSC  to  computerize  contract.  There  is  an 
existing  FAR  deviation  permitting  its  use.  It's  inflexibility 
with  regard  to  use  of  the  DD  250  is  major  problem. 

Question  13  -  Is  there  a  standard  DM  plan  for  responding  to  RFP's  - 
each  RFP  seems  to  require  different  responses  to  how  data  is 
managed. 

Response  13  -  There  is  no  standard  response  or  plan.  Question  adds 
emphasis  to  the  confusion  surrounding  the  DM  function. 

Question  14  -  What  is  the  real  definition  of  a  Data  Manager  and 
associated  career  field?  What  is  the  future? 

Response  14  -  The  answer  to  this  question  is  wrapped  up  in  the  total 
definition  of  the  Data  Management  function  which  needs  to  be 
addressed. 

Action  items  to  be  handled  by  Section  Subcommittee  effort  this  coming 

year: 

1.  Establishment  of  a  consensus  definition  of  the  Data  Management 
function. 

2.  Investigate  feasibility  and  advisability  of  generating  a  DM 
standard  and  the  resulting  recommended  action(s)  which  would  be 
appropriate. 

3.  Initiate  letter  to  FAR(DAR)  committee  recommending  deletion  of  DD 
Form  1660. 

4.  Initiate  letter  to  FAR(DAR)  recommending  major  reduction  in  use  of 
DD  Form  250  for  delivery  of  data. 

5.  Investigate  feasibility  of  use  of  consensus  DID's  for  techinical 
manual  DID's. 

6.  Provide  analysis  of  current  trends  and  recommendations  for  general 
actions  to  be  taken  to  manage  non-traditional  data  (CAD/CAM; 
digitized;  electronic  transfer,  etc.). 


*  Generated  at  pre-workshop  meeting  5/22/79. 


sWhn  R.  Hart 
Chairman 

Data  Management  Section 
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Workshop  #2 

Configuration  Management 
Thursday,  May  24,  1979  -  1315  Hours 


CHAIRMAN:  Mr.  Charles  J.  Embrey 

Northrop  Services,  Inc. 

1700  N.  Lynn  Street 

Suite  1100 

Arlington,  VA  22209 

TELEPHONE:  703-528-5919,  Ext.  385 

PANEL  MEMBERS:  Mr.  T.  W.  Cozine 

Engineering  Specifications  &  Standards  Department 
Naval  Air  Engineering  Center 
Lakehurst,  NJ  08733 

Mr.  J.  W.  Dean 
Hughes  Aircraft 
P.0.  Box  3310 
Fullerton,  CA  92634 

SUBJECTS:  1.  MI L- STD-480/ DoD- STD-48 OA 

Configuration  Control -Engineering  Changes, 
Deviations,  and  Waivers 

2.  DoD-STD-480A,  Appendix  F 

Guidance  for  the  Tailoring  of  DoD-STD-480A  to 
Specific  Program  Requirements 

3.  Questions  and/or  Problems  Posed  by  the 
Workshop  Attendees 

4.  Development  of  an  Action  Item  List  for 
Unanswered/Unresolved  Items  to  be  Worked 
on  During  the  Coming  Year 
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PURPOSE 


The  purpose  of  this  Configuration  Management  Workshop  is  to  utilize  the 
knowledge  gained  by  the  government  and  industry  participants  who  work  with  and 
apply  this  management  discipline  on  a  day-to-day  basis  and  also  improve  communi¬ 
cations  regarding  CM  matters  between  all  of  the  attendees  here  this  afternoon. 

The  objective  of  this  workshop  is  to  identify  and  resolve  problems  which  are 
currently  being  experienced  by  the  attendees  through  questions  and  answers 
posed  by  both  the  panel  and  the  attendees.  Those  problems  which  require  speci¬ 
fication  changes  to  resolve,  or  are  otherwise  too  time-consuming  or  complex  to 
resolve  here  this  afternoon,  will  be  recorded  as  action  items  and  will  be 
addressed  by  the  CM  committee  during  the  coming  year.  Those  of  you  who  wish 
to  participate  as  an  active  member  of  that  committee,  please  indicate  by  placing 
a  "YES"  next  to  your  name  on  the  Attendance  Roster. 

If  you  have  a  question  which  you  wish  to  address  to  the  panel,  or  a  state¬ 
ment  which  you  wish  to  make  to  this  workshop,  please  raise  your  hand.  When  you 
are  recognized  by  the  Chair,  please  state  your  name,  organizational  affiliation, 
and  job  title.  Also,  please  limit  your  initial  statement  or  question,  if  possible 
to  five  minutes.  Again,  we  would  like  to  encourage  your  participation  in  this 
workshop  so  that  we  alj_,  as  a  whole,  might  benefit. 


Configuration  Management 
Workshop  Number  2 

SUMMARY 

Mr.  Ted  Cozine  provided  the  members  of  the  workshop  with  an  overview  of 
some  of  the  differences  between  MIL- STD-480  and  DoD-STD-480A.  The 
chairman  then  opened  the  workshop  for  comments  concerning  DoD-STD-480A. 

The  majority  of  the  comments  received  by  the  panel  were  addressed  to 
paragraph  4.1,  the  last  two  sentences  of  which,  read  as  follows: 

"The  contractor  shall  provide  the  procuring  activity  with  a 
copy  of  the  initial  parts  substitution  list  and  all  changes 
as  they  occur.  An  annotated  parts  list  may  be  used  in  lieu  of 
a  separate  parts  substitution  list  as  mutually  agreed  between 
the  contractor  and  the  procuring  activity." 

Specific  comments  were: 

t  This  is  a  cost  driver  as  it  requires  us_  to  make  separate  listings  for 
those  parts  where  we  have  substituted, 
t  Requiring  an  annotated  parts  list  mutually  agreed  to  by  the  government 
and  the  contractor  is  very  expensive. 

•  The  substituted  part  number  must  be  entered  on  numerous  drawings  and 
logistic  support  data,  which  involves  time  and  money. 

It  was  suggested  by  a  member  of  the  workshop  that  the  government  prepare  a 
list  of  those  parts  and  materials  which  might  be  used  for  substitution. 

It  was  generally  agreed  that  this  was  an  impossible  task  due  to  the  large 
number  of  government  custodians  involved  in  the  preparation  and  maintenance 


of  Mil  Specs.  It  was  then  proposed  that  the  last  two  sentences  of  paragraph 
4.1  be  deleted.  Mr.  T.  Golmis  requested  that  this  subject  be  addressed  as 
an  action  item,  to  be  followed  up  by  members  of  the  panel. 

Mr.  Bill  Dean  provided  the  attendees  with  a  narrative  on  Appendix  F  to 
MIL-STD-480A,  which  is  entitled  "Guidance  for  the  Tailoring  of  DoD-STD-480A 
to  Specific  Program  Requirements."  Even  though  Appendix  F  was  released  by 
the  government  on  29  December  1978,  it  should  be  noted  that  most  of  the 
workshop  members  had  not  received  a  copy.  Mr.  Cozine  indicated  that  action 
was  being  taken  to  alleviate  this  problem.  Mr.  Dean  then  explained  that 
this  appendix  is  unique  in  that  it  "serves  as  a  guide  for  the  activity 
responsible  for  the  preparation  of  contract  requirements  and,  as  such, 
shall  not  in  itself  form  a  part  of  the  contract." 

The  following  previously  prepared  statements  and  questions  from  the  members 
of  the  workshop  were  addressed  by  the  panel : 

QUESTION:  What  is  the  timetable  for  the  release  of  MIL-STD-XXX? 

ANSWER:  The  current  DoD  CM  Standardization  Program  Plan  calls  for  a 

release  by  the  fourth  quarter  of  CY  1980. 

QUESTION:  Has  there  been  a  DID  prepared  for  invoking  480A  on  contracts? 
ANSWER:  480A  is  itself  invoked  on  the  contract  and  associated  DIDs  are 

then  entered  on  the  CDRL  for  ECPs,  deviations,  waivers,  etc. 

QUESTION:  Are  there  definitions  that  provide  enough  information  to  delineate 
the  difference  between  Data  Management  and  CM? 

ANSWER:  DM  is  the  management  of  data  and  the  costs  associated  with  the 

preparation  and  delivery  of  data.  CM  is  a  management  discipline  which 
encompasses  both  hardware  and  all  of  its  associated  data. 

QUESTION:  AFSC/ESD  requires  that  section  2  of  specifications  cal  1  for  the 
specific  issue  of  referenced  documents  by  revision  letter,  notice  number, 
and  date.  Why  is  the  date  necessary? 


ANSWER: 


It  is  required  by  ASPR. 


QUESTION:  How  is  the  Military  and  Industry  handling  the  abbreviation  of 
long  Mil  Spec  numbers  on  drawings  and  associated  lists,  computerized  lists, 
and  Bills  of  Material?  There  is  a  problem  when  the  computer  part  number 
field  has  limitations. 

ANSWER:  Many  companies  are  maintaining  separate  listings  of  internal 

numbers  to  maintain  those  spec  numbers  which  exceed  the  computer  field. 
QUESTION:  MIL-STD-480  and  DoD-STD-480A  specify  criteria  for  classification 
(Class  I)  of  engineering  changes.  These,  at  best,  are  ambiguous  and  hard  to 
interpret;  480B  must  require  tailoring  of  criteria  to  each  program  and  change 
the  specified  criteria  to  guidelines.  One  set  of  criteria  never  can  apply 
to  many  different  programs. 

ANSWER:  This  subject  was  discussed  by  the  attendees  and  panel  members.  It 

was  not,  however,  fully  explored  and  it  was  not  part  of  the  agenda  for  this 
workshop. 

ACTION  ITEMS 

MIL-STD-480A,  paragraph  4.1,  will  be  addressed  by  the  panel  and  a  proposed 
resolution  drafted. 

CONTINUING  ACTION  ITEMS 

Mr.  C.  Embrey  will  provide  workshop  members  with  updated  joint  DoD  CM 
Standardization  Program  Plans  and  drafts  of  CM  documents  for  comment,  as  they 
become  available. 
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1.  Q.  Why  are  dates  specified  for  industry  standards  in  the  applicable 

specification  section  of  a  government  standard  or  specification  but 
not  specified  for  applicable  military  standards  or  specifications? 

A.  The  government  does  not  control  when  industry  revises  their  documents. 
Only  those  industry  standards  and  specifications  which  the  government 
has  approved  are  usable  in  contracts.  Each  specific  issue  must  be 
approved.  The  issues  are  controlled  by  the  document  date. 


2.  Q.  Why  are  there  two  non-government  documents  covering  the  same  subject 
listed  in  D0D-STD-100C?  Example:  IEEE-STD-31 5-1975  and  ANSI-Y32.2- 
1975. 

A.  In  the  past,  when  a  document  was  submitted  to  ANSI  for  approval,  it 
was  assigned  an  ANSI  peculiar  number.  Presently,  ANSI  has  discontinued 
assigning  new  numbers  and  instead  prefixes  the  subcommittee  number. 
There  will  be  a  transition  period  until  a  document  with  two  numbers  is 
revised;  at  that  time  the  numbers  will  be  replaced  with  a  single 
identifier. 


3.  Q.  What  is  the  meaning  of  "certification"  as  referenced  in  Para.  504.1.3 
of  MIL-STD-100B? 

A.  Certification  refers  to  the  signature  of  a  qualified  person  who  verifies 
that  the  change  was  accurately  and  completely  incorporated  into  the 
document. 


4.  Q.  Re-identification  "up  to  and  including  the  assembly  where  interchange- 
ability  is  re-established"  as  required  in  Para.  1-302.14-3,  Item  C, 
was  "proven"  unworkable  and  changed  in  Rev.  B.  Why  was  it  changed 
back  in  Rev.  C? 

A.  Industry  outcry  over  the  change  in  Rev.  B  brought  about  the  change  in 
Rev.  C  to  what  it  was  prior  to  Rev.  B.  Opponents  far  outnumbered  the 
proponents.  To  them  it  was  never  unworkable. 


5.  Q.  Have  slash  sheets  to  D0D-D-1000  been  cancelled,  and,  if  not,  will  they 
be? 

A.  Not  yet.  AFAD  71-700  is  slated  to  be  cancelled  on  June  1,  1979,  and  a 
cancellation  notice  for  the  others  will  be  issued. 


6.  Q.  If  no  tailoring  is  specified  in  a  contract,  how  should  a  contractor 
interpret  D0D-D-1000? 

A.  If  you  sign  a  contract  for  drawings  in  accordance  with  D0D-D-1000 
without  the  procurement  document  completed  in  accordance  with 
Para.  6.2,  you  have  bought  it  all.  In  other  words,  don't  sign. 


7.  Q.  D0D-STD-100C  says  that  the  letters  "S"  and  "Z"  and  others  shall  not 
be  used.  (Re  Para.  402. 5. a.)  Do  I  have  to  change  present  practices 
and/or  change  revisions? 

A.  Para.  402. 5. a  allows  for  the  continued  use  of  letters  "S"  and  "Z"  if 
they  are  part  of  an  existing  drawing  numbering  system. 


8.  Q.  Is  it  all  right  for  a  company  to  make  control  drawings  of  MS  parts  and 
charge  overhead  on  a  military  contract?  If  not,  how  can  it  be  stopped? 

A.  Para.  3.6  of  D0D-D-1000B  states  that  engineering  drawings  shall  not  be 
prepared  or  submitted  for  items  that  are  defined  by  government  specifi¬ 
cations,  standards,  or  nationally  recognized  industry  association 
specifications  or  standards. 

On  the  other  hand,  because  of  company  practices,  Para.  402.11.2  of 
D0D-STD-100C  allows  the  following  parenthetical  identifier.  "Using 
design  activity  identifying  numbers  may  be  referenced  parenthetically 
to  identify  in-house  peculiar  identities." 

Interpreting  the  two  statements  above,  if  for  peculiar  in-house 
requirements  it  is  necessary  to  prepare  drawings  or  have  in-house 
identifiers  for  MS  parts,  the  in-house  number  is  a  reference  number 
and  would  be  shown  parenthetically  with  the  MS  number,  which  is  the 
prime  callout  on  the  drawing  or  list.  It  is  the  intent  of  the  standards 
not  to  create  redundant  data. 


9.  Q.  Please  discuss  the  conversion  of  design  development  drawings  to  produc¬ 
tion  phase  drawings  and  any  special  problems  involved. 

A.  Amendment  1  to  D0D-D-1000B,  "Guide  for  Application  and  Tailoring  of  the 
Specification,"  has  as  its  prime  purpose  the  clarification  of  the 
differences  in  the  various  phases  of  a  program. 

The  differences  between  a  drawing  package  for  a  development  program  and 
a  production  program  are  the  types  and  quantities  of  drawings  needed  to 
build  the  hardware  for  the  particular  contract.  Such  factors  as:  (1) 
quantity  of  items  to  be  built,  (2)  where  the  articles  are  to  be  built 
in  your  facility  (model  ship  or  production  floor),  (3)  engineering 
build  vs.  full  manufacturing  controls,  etc.,  determine  what  types  of 
drawings  are  necessary.  (See  Para.  30.3.1  of  Amendment  1  to  D0D-D-1000.) 


9.  A.  (Continued) 


Levels  are  not  to  be  interpreted  as  three  levels  of  drawing  quality 
(good,  better,  best)  that  a  drafting  department  can  create  on  their  own 
from  a  drafting  manual.  When  someone  orders  a  Level  3  production  drawing 
package  during  initial  development  phase,  this  is  an  indication  of  lack 
of  understanding  and  a  misconception  of  the  standards  on  their  part. 

Hardware  manufacture  relates  to  phases  of  a  program;  i.e.,  conceptual, 
development,  limited  production,  production,  etc.  Phases  of  a  program 
relate  to  levels.  Levels  relate  to  the  standards  and  drawing  practices. 
Para.  3.4.3  of  D0D-D-1000  states,  "Unless  otherwise  specified  in  the 
contract  or  order  (see  6.2.1),  the  contractor  is  responsible  for  the 
selection  and  number  of  engineering  drawings  necessary  to  satisfy  the 
content  and  requirements  of  the  level (s)  ordered." 


10.  Q.  How  do  you  call  out  items  in  parts  lists  and  drawings  that  are  covered 

by  federal  specifications  where  no  part  or  identifying  numbers  are  provided? 

A.  A  description  is  used  (e.g.  3/9  inch  box  wrench  per  QQ-X-XXX).  See 
question  11  for  additional  information. 


11.  Q.  How  can  part  numbers  be  handled  where  no  part  number  is  available  and  a 

description  must  be  used;  or  part  numbers  that  exceed  15  digits;  or 
same  number  but  are  i nadvertentl y  written  differently,  such  as  omission 
or  insertion  of  a  space,  slash,  period,  etc.?  What  provisions  are  being 
made  to  accommodate  computer  printed  lists? 

A.  Many  companies  make  cross  reference  type  drawings  which  assign  a  DOD-STD-lOO 
compliant  number  to  items  with  descriptive  identifiers  or  identifiers  exceeding 
15  digits.  (It  was  reported  that  the  ANSI  Y14.24  Committee  on  Types  of 
Drawings  is  contemplating  an  "Identification  Control  Drawing"  to  handle  that 
problem. ) 

In  relation  to  the  other  question  of  omissions,  insertions,  slashes, 
etc.,  most  companies  have  similar  problems.  It  requires  training  of 
drafting  personnel  and  personnel  inputting  to  the  computers. 

12.  Q.  Do  logic  diagrams  have  to  be  made  and  submitted  to  meet  D0D-D-1000 

requirements  even  though  they  are  not  required  by  internal  plant 
operation  for  digital  PCB's?  Can  computer  generated  "engineering  lists" 
and  logic  "implementation  lists"  be  considered  a  suitable  substitute? 

A.  Although  the  type  of  data  to  support  a  particular  line  item  of  the  contract 
is  the  responsibility  of  the  contractor  according  to  D0D-D-1000,  Para. 

3.4.3,  it  still  must  meet  the  requirements  to  satisfy  the  total  function 
the  particular  hardware  is  to  be  used.  This  may  include  data  to  support 
interface  control,  logistic  support,  maintenance,  government  manufacture, 
etc.  The  agreement  on  the  data  package  contents  should  be  reviewed  in 
that  light  with  customer  concurrence  on  any  doubtful  areas. 
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12  A.  (Continued) 


It  was  the  opinion  of  the  panel  that  it  would  be  unlikely  that  data  to 
support  digital  PCB's  would  be  complete  without  logic  diagrams  to 
support  design  evaluation,  future  engineering  changes,  manuals,  etc., 
unless  the  program  is  so  peculiar  that  only  data  to  support  manufacture 
is  required  with  no  additional  objectives. 


13.  Q.  MIL-STD-275  Master  Drawings  -  Should  the  hole  count  include  test  coupons? 
A.  The  hole  count  should  state  if  it  includes  the  test  coupon  holes  or  not. 


14.  Q.  MIL-STD-275  -  Is  there  a  preferred  format  for  showing  manufacturing 
allowances? 

A.  No.  It  is  our  understanding  that  IPC  is  considering  one. 


15.  0.  What  is  a  non-drawing  copy?  Non-drawina  copies  are  called  out  in 

MIL-D-5480. 

A.  This  question  was  referred  to  John  Sutton,  Chairman  of  the  ADPA/TDD 

Micro-Reporduction  Section.  John's  investigation  produced  the  following. 
A  non-drawing  copy  is  a  copy  made  from  documents,  such  as  parts  lists, 
wire  lists,  bookform  drawings,  specifications,  etc.  It  appears  that  any 
document  including  certain  types  of  drawings  as  specified  in  D0D-STD-100, 
which  are  text  and  not  dimensional  items,  fall  under  the  present 
definition.  John  reported  that  the  preparing  activity  of  MIL-D-5480 
recognizes  the  problem  with  the  clarity  of  the  term  and  will  take  future 
action  to  rectify  the  problem. 


16.  Q.  What  are  companies  doing  to  reduce  the  release  of  duplicate  parts  and 
to  control  usage  of  military  part  numbers? 

A.  Many  companies  develop  parts  selection  documents  which  contain  company, 
industry,  and  military  standards.  They  require  their  design  personnel  to 
select  parts  for  new  designs  from  the  parts  selection  document  which  will 
then  control  the  usage  and  release.  Further  some  automated  parts  listings 
systems  are  in  use  which  restrict  the  output  to  those  items  which  are 
contained  in  a  master  file.  Entries  to  this  master  file  are  tightly 
controlled  to  prevent  entry  of  unauthorized  items. 


There  were  numerous  questions  that  referred  to  Specification  or 
Source  Control  Drawings. 


It  was  decided  by  the  panel,  with  no  objections  from  the  work¬ 
shop  attendees,  that  those  questions  should  not  take  up  any 
time  because  of  the  current  work  in  process. 

The  Engineering  Drawing  Requirements  Section  of  ADPA/TDD,  at  the 
request  of  the  Department  of  Defense,  has  undertaken  the  task  of 
reviewing  the  present  definitions  and  requirements  of  Specification 
Source  Control  Drawings  in  the  D0D-STD-100.  There  is  an  18 
member  special  committee  already  functioning.  The  committee  will 
coordinate  its  findings  and  recommendations  with  the  ANSI  Y14.24 
Committee  on  Types  of  Drawings. 


NOTE:  For  those  who  did  not  obtain  copies,  the  Summary  of 
Changes  Incorporated  into  D00-STD-100C  distributed  at  the 
workshop  are  included  in  section  Y  of  these  proceedings. 


ACTION  ITEMS  FOR  THE  ADPA  DRAWING  REQUIREMENTS  SECTION 


DOD-STD-IOOC,  Para.  107  presently  calls  out  a  requirement  for  a  caution  note 
when  the  drawings  are  for  items  using  radioactive  materials.  Is  the  note 
too  restrictive  by  referring  only  to  radioactive  materials  when  there  are 
other  materials  that  could  also  be  categorized  as  hazardous? 

There  is  nothing  presently  called  out  in  D0D-STD-100  referring  to  or 
defining  "firmware." 

The  present  DOD-STD-IOOC  does  not  cover  how  to  define  alternate  parts  (not 
substitute)  on  drawings  or  parts  lists. 

Some  elements  of  the  Air  Force  and  Navy  through  DID's,  AFAD's  etc.,  require 
an  application  block  (or  referenced  list)  on  all  assembly  drawings.  The 
block  requires  next  assemblies  and  quantities.  With  the  high  initial 
expense  and  recurring  update  cost,  why  do  they  have  this  requirement. 

Para.  502.3  of  DOD-STD-IOOC  requires  that  when  a  drawing  is  revised,  the 
latest  applicable  approved  standard  shall  be  used.  The  requirement  is 
mandatory,  which  could  cause  problems. 

Assist  in  the  preparation  of  a  specification  or  standard  for  handling 
computer  graphics.  Present  drawing  documents  do  not  adequately  address  this 
growing  problem. 

An  action  item  for  the  Micro-Reproduction  Section  arose  in  this  workshop 
and  was  passed  on  to  John  Sutton,  Chairman  of  that  ADPA/TDD  Section.  Certain 
contractors  are  meeting  the  requirements  of  MIL-M-9868  of  fifth  generation 
quality  by  using  super  sharp  cameras  whose  capability  exceeds  that  of 
standard  microfilm  equipment.  It  was  suggested  that  the  specification 
MIL-M-9868  be  reviewed  for  possible  change  to  identify  use  of  standard 
rather  than  special  equipment. 

An  action  item  arose  as  a  result  of  a  discussion  about  the  addition  of 
nameplates  by  a  using  activity  on  end  items  of  another  design  activity. 

The  addition  of  the  nameplate  requires  the  preparation  of  either  another 
higher  level  assembly  drawing  or  an  altered  item  drawing.  This  adds 
costs  and  reidentifies  the  assembly  from  the  true  design  activity 
number  to  the  using  activity  number.  This  action  item  will  be  referred 
to  the  MIL-STD-130  preparing  activity. 
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It  has  been  almost  20  years  since  I  became  Chairman  of  the 
Preparation  and  Management  of  Specification  Committee  of  the  ADPA. 
Since  that  time,  this  field  of  documentation  has  become  more 
widely  used  as  mors  and  more  complex  systems  were  conceived, 
developed  and  produced.  We  have  seen  the  establishment  of  re¬ 
quirements  for  various  types  of  program  peculiar  specifications 
and  the  practices  to  be  used  in  their  preparation,  management  and 
control.  Today,  they  play  a  major  part  of  every  engineering  data 
package.  They  are  a  part  of  the  established  management  system 
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for  the  acquisition  of  equipments  for  DcD  use.  This  includes  the 
Systems  Engineering,  Configuration  Management  and  Data  Management 
functions  that  extend  from  concept  through  production  and  maint¬ 
enance.  Program  pe  culiar  specifications  address  baseline  manage¬ 
ment  through  each  phase  of  acquisition. 

At  the  last  workshop  a  year  ago,  we  were  given  first-hand  knowledge 
of  an  effort  combining  the  requirements  of  Mil-Std-490  and  Mil-Std- 
961  to  form  one  comprehensive  set  of  requirements  and  practices 
for  industry  as  well  as  the  military  to  follow  in  preparing  spec¬ 
ifications.  Unfortunately,  when  the  actual  combined  standard 
was  made  available  to  industry  and  the  military  for  review,  it 
fell  far  short  of  the  goals  which  were  to  be  achieved. 

One  of  the  reasons  given  for  the  establishment  of  the  combined 
standard  was  to  facilitate  the  conversion  of  a  program  peculiar 
specification  to  a  military  specification.  It  was  the  unaninous 
opinion  of  many,  that  the  chance  of  a  weapons  system  family  of 

program  peculiar  specifications  ever  being  converted  into  a 
military  specification  format  was  extremely  remote.  Industry, 
in  general,  felt  that  the  alleged  conversion  problems  were 
vastly  overstated,  were  not  of  such  monumental  or  of  cost  in¬ 
curring  nature  as  to  warrant  the  requirement  presented  by  the 
combined  standard. 

A  further  review  of  the  combined  standard  made  it  apparent  that 
there  would  have  to  be  an  extensive  re-evaluation  of  existing 
system  management  practices  (DID's  and  other  procurement  devices) 
before  it  could  be  released  for  contractural  use.  The  task  of 
changing  references,  definitions,  etc.  alone  is  staggering.  Addi¬ 
tionally,  it  has  taken  industry  10  years  to  fully  implement  Mil- 
Std-490  and  its  associated  documents.  The  changes  that  are  in¬ 
cluded  in  the  combined  standard  would  tend  to  disrupt  all  the 
progress  to  date  in  the  application  of  the  Mil-Std-490  concept. 

It  was  the  understanding  of  many  that  the  combined  standard  would  be 
limited  to  editorial,  language,  and  format  practices.  In  this  re¬ 
gard,  the  combined  standard  introduces  new  and  confusing  practices 
dealing  with  table  numbering,  page  numbering  and  identification, 
section  headings,  appendix  numbering,  definitions,  etc.  The  com- 


bined  standard  offers  nothing  new  to  the  management  process,  but 
rather  imposes  a  host  of  "how  to"  requirements  which  are  different 
frcm  present  requirements. 

It  is  recognized  that  a  considerable  effort  was  put  forth  in  the 
attempt  to  combine  these  documents  into  one  comprehensive  standard. 
However,  the  combining  of  these  standards  did  not  accomplish  the 
results  envisioned  during  the  formulation  of  the  plan.  As  a  re¬ 
sult,  it  was  suggested  that  the  program  be  discontinued. 

It  was  also  the  consensus  of  many  that  any  new  efforts  on  the  part 
of  the  DoD  Standardization  Office  to  improve  specifications  be 
aimed  at  updating  Mil-Std-490  to  include  the  applicable  portions 
of  Mil-Std-483.  It  was  also  recommended  that  Mil-Std-490  be  up¬ 
dated  as  soon  as  possible  to  reflect  the  experiences  gained  by 
industry  in  applying  this  document  contractually . 

Everyone  heard  yesterday  that  the  project  for  combining  the  two 
existing  standards  into  one  document  was  cancelled  due  to  the  over¬ 
all  negative  response  from  the  military  as  well  as  the  industry.  It 
was  also  stated  that  consequently  we  can  all  expect  to  see  the  pending 
revision  to  Mil-Std-961  be  implemented  soon  and  that  the  overdue 
revision  to  Mil-Std-490  will  be  forthcoming  in  the  very  near  future. 

It  is  expected  that  the  revisions  to  both  of  these  documants  will  pick 
up  and  eliminate  where  possible  those  differing  and  conflicting  require 
ments  now  existing  between  them  in  the  editorial,  language,  and 
format  practices. 


QUESTION  AND  ANSWER  SESSION: 
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Program.  Peculiar  Specifications  (as  defined  by  Mil-Std-490)  are 
used  as  a  guide  by  one  of  the  services  (NAVAIR)  to  document  an  item 
during  developement  and  initial  production.  ASPR/DARS  requirements 
state  that  if  they  are  used  for  more  than  one  procurement  that  they 
be  converted  to  Military  Specifications.  In  reality,  the  requirement 
should  be  changed  to  convert  them  only  when  they  are  used  in  more 
than  one  application,  permitting  the  use  of  program  peculiar  specifica¬ 
tions  for  repeat  procurement.  In  addition,  program  peculiar  specifica¬ 
tions  normally  go  through  many  changes  during  the  life  cycle  of  a 
program.  Military  Specifications  do  not  lend  themselves  to  quick 
change/revisicn  application.  Mr.  Mitchell  informed  the  attendees 
that  this  problem  area  should  be  addressed  in  the  forthcoming  EARS 
replacing  DARS  1-1202.  NAVAIR  should  make  special  effort  to  have  their 
voice  heard  during  the  comment/approval  cycle  of  the  proposed  FARS . 

This  is  the  vehicle  for  getting  proper  recognition  for  official  use 
by  the  services  to  use  program  peculiar  specifications  for  specific 
purposes . 


2. 


Mii-Std-490  carries  a  requirement  for  "Documentation"  in  para. 3.4  of 
the  System  and  Type  B  Developement  Specifications.  Hew  is  this  being 
responded  to  by  Industry?  First  of  all,  the  requirement  for  documenta¬ 
tion  does  not  belong  in  these  type  specifications  but  in  a  Statement 
cf  Work  (SOW)  or  documents  associated  with  a  SOW.  For  years,  the  ADPA 
Specifications  Committee  has  tried  to  get  this  requirement  removed 
from  Mil-Std-490  but  as  you  all  know  we  are  still  awaiting  for  a 
revision  to  that  document.  Its  been  almost  ten  years  since  it  first 
was  issued  and  used  in  contracts.  At  the  present  time,  most  of  us  are 


simply  responding  with  "Not  Applicable". 

How  does  Industry  handle  classified  information  in  a  specification? 

The  simplest  way  to  handle  this  criteria  is  to  put  it  in  an  Appendix 
to  the  basic  specification  and  only  have  the  appendix  classified.  For 
the  same  type  of  situation  in  the  Mil-Std-961  system,  the  present 
version  of  this  document  does  not  adequately  cover  this  technique. 

I  understand  the  proposed  revision  will  but  will  call  the  attachment 
an  "Extract". 


4.  The  effective  use  of  tailoring  techniques  during  the  RFP  stage  was 
discussed  extensively.  Most  companies  are  submitting  two  responses, 
one  in  total  compliance  and  the  other  with  tailoring  applied.  However, 
there  has  been  some  reluctance  to  participate  in  this  DOD/Industry 
feedback  effort  because  there  is  a  belief  that  proposals  are  not 
safeguarded  from  competitors,  that  alternate  proposals  reduced  Value 
Engineering  Change  Proposal  possibilities,  and  that  the  cost  of 
alternate  proposals  would  not  pay  off  unless  the  contractor  won  the 
competition . 

5.  Is  the  practice  of  defining  multiple  Cl  versions  within  a  Mil-Std-490 
Type  B  and  C  specification  acceptable?  I  personnally  have  not  seen 
todate  any  application  of  this  technique  to  program  peculiar  specifica¬ 
tions  generated  by  Industry.  I  think  it  would  be  quite  difficult  to 
apply  configuration  management  principals  using  type  numbers  to 
address  different  configurations.  The  Mil-Std-490  system  permits  the 
use  of  an  Addendum  Document  to  define  the  same  type  of  item  for  a 
different  mission  and  this  is  the  one  I've  seen  used  most. 

6.  Will  the  DlD's  for  Computer  Program  Cl  Part  I  and  II  Specifications 
shown  in  Change  Notice  2  of  Mil-Std-483  be  updated?  As  far  as  I  know 
the  updating/revision  of  all  DID's  is  one  of  the  tasks  in  the  overall 
Configuration  Management  Plan  for  the  near  future.  I  would  assume  the 
specific  DID's  I  just  mentioned  would  be  first  on  that  agenda. 

7.  In  4120.3m  Chapter  VII  Section  2  (7-202,203,204)  requires  that  the 
Contract  Specification  incorporate  Configuration  &  Data  Management 
activities  and  documentation  (drawings,  specifications,  etc.).  DOD 
Directive  5000.19  (Enclosure  5)  para.V,  C3  requires  that  all  manage¬ 
ment  systems  and  data  requirements  to  be  selected  from  DOD  Directive 
5000. 19L  shall  be  listed  in  a  single  location  in  solicitations  and 
contracts  (part  of  SOV7)  .  Which  is  the  correct  application?  An  action 
item  was  given  to  Mr.  Mitchell  to  clarify  and  notify  the  attendees 
of  his  finding. 

8.  Information. 

a)  Change  Notice  2  of  Mil-Std-483  (USAF)  is  being  printed. 

b)  The  "Systems  Management  Newsletter"  which  is  issued  quarterly  is 
yours  for  the  asking  by  writing  HQTRS ,  AFSC/SDDS , ANDREWS  AFB, 

DC  20334,  ATTENTION:  Major  T.L.LEIB,  JR. 
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WORKSHOP  #5 

ils/technical  PUBLICATIONS 
MEETING  REPORT 

WORKSHOP  PARAMETERS  -  The  ILS/Techni cal  Publications  Workshop  was  conducted  from 
1345  to  1700  on  May  24,  2979,  in  classroom  368,  Ingersoll  Hall,  Naval  Postgraduate 
School,  Monterey,  California.  This  workshop  was  a  part  of  the  Twenty  First  Annual 
Meeting  of  the  Technical  Documentation  Division,  American  Defense  Preparedness 
Association. 

Workshop  #5  was  attended  by  17  participants  (6  military  and  11  industry  repre¬ 
sentatives).  The  roster  identifies  each  participant  by  name  and  affiliation. 

OVERVIEW  -  The  Workshop  Chairman  convened  the  session  by  presenting  a  brief  report 
on  the  status  of  last  years  action  items.  Two  areas  of  follow-up  action  were 
reported.  The  first  area  involved  ADPA's  offer  to  assist  Army  personnel  in 
presenting  the  Integrated  Technical  Documentation  and  Training  (ITDT)  concept  and 
implementation  procedures  in  a  series  of  5-day  workshops  to  be  held  at  East  Coast, 
West  Coast  and  Central  cities.  This  workshop  program  is  still  pending  but  the 
concept  is  now  identified  as  Skill  Performance  Aids  (SPA).  The  second  area  involved 
assistance  in  the  Technical  Manuals  Specifications  and  Standards  (TOSS)  program. 

We  have  contributed  our  effort  to  the  industry  team  led  by  NSIA  and  joined  by 
AIA.  This  Tri-Service  Program  is  chaired  by  Mr.  Roy  Post  at  the  U.S.  Army 
Maintenance  Management  Center,  Lexington,  Kentucky.  We  contemplate  considerable 
activity  in  future  actions  associated  with  TOSS. 

After  the  introductory  report,  the  purpose  and  operating  procedures  for  the  work¬ 
shop  session  were  given.  During  the  General  Membership  Meeting  (Session  1  on 
May  23,  1979),  "Question/Problem n  forms  were  distributed  to  all  attendees  and  the 
five  ADPA  workshops  and  workshop  chairmen  were  introduced.  As  a  result  of  this 
solicitation,  Workshop  #5  received  nine  "Question/Problem"  responses  that  were 
used  as  the  workshop  issues  for  discussion.  To  prepare  for  the  discussion,  each 
participant  in  Workshop  #5  was  asked  to  identify  individual  background  information 
such  as  name,  affiliation,  position,  and  brief  sketch  of  applicable  experience. 

The  Workshop  Chairman  then  stressed  that  each  participant  should  contribute  to 
the  session  as  an  individual  rather  than  as  a  representative  of  the  affiliated 
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company  or  military  service.  Using  this  approach,  the  workshop  objective  was 
established  as  the  resolution  of  "Question/Problem"  issues  that  would  best 
serve  American  defense  preparedness. 

Each  of  the  nine  input  issues  was  addressed  during  the  workshop  session.  Seven 
of  the  problems  were  resolved  during  discussion  and  two  require  follow-up  action 
Details  of  eaeh  issue  follow  with  coverage  of  question  asked,  discussion  high¬ 
lights  and  resolution  or  follow-up  action  to  be  taken. 

SPREAD  OF  SPA  (FORMERLY  ITDT) 

The  SPA  concept  (formerly  ITDT)  for  Technical  Manuals 
is  being  implemented  by  the  Army,  essentially  changing 
"Technical  Manual"  content  to  "Training  Manual"  content. 

Does  the  Technical  Documentation  Division  of  ADPA  know 
if  this  concept  will  be  carried  through  to  USAF,  Navy, 
and  Marine  Corps  of  DOD? 

DISCUSSION  HIGHLIGHTS:  Background  information  from  the  ADPA  20th  Annual 
Meeting  at  New  Orleans  was  discussed.  Also,  reference  was 
made  to  the  "AFALD  Lessons  Learned  Bulletin-Technical 
Orders"  furnished  by  Major  L.  Nesbitt.  Concepts  such  as 
Logistic  Support  Analysis,  user  oriented  instructions, 
full  validation  and  verification,  cross  feed  of  on  the  job 
training  and  multi-media  presentation  were  highlighted. 

These  concepts  were  then  related  to  current  TMSS  efforts. 

RESOLUTION:  By  virtue  of  the  IMSS  effort,  the  concepts  will  certainly 
be  examined  by  the  tri-service  program.  It  is  highly 
unlikely  that  SPA  will  be  applied  across  the  board.  It 
is  more  probable  that  the  key  elements  of  the  concepts 
will  be  applied  in  unrecognizable  SPA  form. 


WORKSHOP  ISSUE  1  - 
QUESTION: 


WORKSHOP  ISSUE  2  -  PROLIFERATION  OF  DID's 
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WORKSHOP  ISSUE  3 
QUESTION: 

DISCUSSION 


Can  the  ADPA  Technical  Documentation  Division  address 
a  problem  with  the  proliferation  of  mods,  addenda, 
attachments  to  Data  Item  Descriptions  (DID's)  when  the 
DID's  are  inserted  on  the  DD1423  in  IFB's,  RFQ's,  etc.? 

The  mods,  addenda,  and  so  forth,  are  destroying  the 
intent  of  MIL  Specs  to  standardize  the  form  and  contents 
of  data  items. 

HIGHLIGHTS:  The  basic  use  of  the  "grocery  list"  approach 
to  identifying  contractual  data  items  was  discussed. 

This  led  to  a  discussion  of  how  the  many  service  organiza¬ 
tions  implemented  the  DDD  guidance.  Reference  was  made 
tc  the  major  ADPA  effort  of  the  70 's  that  did  make 
recommendations  in  each  of  the  categories  (including 
the  "H"  category).  The  time  and  effort  expended  by  ADPA 
membership  did  not  result  in  any  noticeable  change  nor 
did  we  realize  an  interface  discussion. 

Before  ADPA  attempts  another  pass  at  reducing  DID 
proliferation,  we  will  be  sure  to  establish  firm  communica¬ 
tion  commitments  at  the  initial  phase  of  such  a  program. 

(In  the  subsequent  briefing  to  the  general  membership, 
assistance  va;>  offered  to  the  Data  Management  Section 
of  ADPA.  This  assistance  will  take  the  form  of  passing 
along  the  results  of  our  earlier  effort.) 

-  TRAINING  AND  QUALIFICATIONS  -  TECHNICAL  AUTHORS 

What  is  the  United  States  doing  about  training  and  qualifica¬ 
tions  for  technical  authors  and  communicators? 

HIGHLIGHTS:  Reference  was  mad0  h>  an  ADPA  Technical  Publications 
Section  sub-committee  study  conducted  in  the  60’s.  This  study 
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had  concluded  that  the  diversity  of  government  and 
industry  needs  precluded  attempts  to  establish  training 
and  qualification  guidelines.  Discussion  of  current 
practice  within  workshop  participant  organizations  high¬ 
lighted  that  such  diversity  continues. 

RESOLUTION:  Based  on  the  earlier  study  and  current  trends,  ADPA  does 
not  intend  to  trigger  a  new  effort  on  this  issue.  The 
UK  representative  was  given  the  following  follow-up  leads 
to  assist  in  his  study: 

East  Coast:  Rensselaer  Polytechnic  Institute 
(Writers  Institute) 

Brooklyn  Polytechnic  Institute 
( B3  -  Technical  Communication) 

Central:  University  of  Illinois 

West  Coast:  UCLA  (Seminars) 

Also,  the  Society  of  Technical  Communicators  was  recommended 
as  a  contact  point.  Those  references  were  not  identified 
as  a  complete  listing  but  rather  as  excellent  starting 
points. 

WORKSHOP  ISSUE  4  -  PREMATURE  ACQUISITION  OF  PRODUCTION  DATA 

PROBLEM:  Resolve  the  premature  application  of  full-up  specifications 
and  standards  to  ILS  disciplines/ elements,  LSA,  LORA, 
Technical  Manuals,  Training,  etc.,  for  development 
programs . 

DISCUSSION:  This  problem  induced  a  thorough  discussion  of  tailoring 

of  specification  and  standards  to  program  needs.  Reference 
was  made  to  an  initial  TMSS  input  from  ADPA  that  called 
for  attention  to  tailoring  of  requirements.  Communication 
with  ILS  customer  counterparts  at  the  early  contract  stages 
is  essential  to  clarify  intent  and  avoid  misinterpretation. 


Alternate  approaches  are  now  encouraged  by  most  RFP's. 

The  climate  for  resolving  such  problems  is  much  improved 
by  use  of  life  *ycle  cost  analysis. 

RESOLUTION:  Implementation  of  tailoring  techniques  on  a  program  need 
basis  is  now  encouraged  by  DOD.  This  avenue  of  approach 
also  provides  increased  communication  capability  with 
customer  counterparts. 

WORKSHOP  ISSUE  5  -  FUTURE  TRENDS  IN  DEMAND  FOR  DOCUMENTATION 

QUESTION:  What  is  the  future  di^ection/emphasis  of  technical 

documentation!  particularly  with  respect  to  technical 
manuals,  metrication,  micro  reproduction,  PM3,  etc.? 

Will  requirements  to  contractors  be  increasing  or 
decreasing? 

DISCUSSION  HIGHTLIGHTS:  Reference  was  made  to  the  DCD  activity  summary 
given  at  general  membership  Session  II.  The  GAO  interest 
in  technical  manuals  vas  related  to  the  USAF  and  USN 
retrenchment  from  micro  reproduction  and  the  costs  of 
earlier  investments.  This  would  indicate  that  future 
trends  in  micro  reproduction  are  subject  to  very  careful 
analysis.  Discussion  brought  out  the  relatively  slow  but 
steady  trend  toward  metrication.  Perhaps  the  greatest 
impact  will  be  felt  as  a  function  of  technology  progression. 
Built  in  test  equipment  (BITE),  preventive  maintenance  (PM) 
and  fault  localization  (FL)  circuitry  in  current  systems 
were  discussed  and  related  to  demands  for  documentation. 
Participants  were  asked  to  review  the  10-year  forecast 
made  by  AIA  at  the  start  of  the  70' s.  Much  of  that  forecast 
could  now  be  applied  to  our  forecast  for  the  80' s. 


RESOLUTION:  Progress  in  technology  will  provide  the  key  to  future 
trends.  We  can  only  be  assured  of  continuing  change. 
Hopefully,  progress  will  continue  in  manageable  doses. 


VQRKgHO?  I  Soil  E  6  -  MAKING  MAXIMUM  USE  OF  EXISTING  REPRO 


PROBLEM:  Specification  MIL-M-38784A  does  not  contain  provisions  for 

use  of  "lifts"  from  existing  books  done  to  prior  revisions 
or  different  specifications.  (A  statement  such  as  that 
contained  in  DQD-D-1000  for  existing  drawings  is  recommended.) 

DISCUSSION  HIGHLIGHTS:  Discussion  highlighted  the  contractual  implement¬ 
ing  documents.  Tailored  to  specific  program  needs,  it  is 
in  such  documents  that  encouragement  or  discouragement  of 
"lifts"  is  given.  Placing  such  a  statement  in  the  technical 
manual  specification  would  be  a  mistake  but  data  acquisition 
personnel  must  be  made  aware  of  this  approach. 

RESOLUTION:  No  attempt  will  be  made  by  ADPA  to  add  such  a  statement 
to  MIL-M-38784A.  Perhaps  the  TMSS  Tri-Service  committee 
could  be  encouraged  to  improve  the  awareness  of  data 
acquisition  personnel  to  the  proper  use  of  contractual 
implementing  documents  where  this  issue  is  applicable. 

WORKSHOP  ISSUE  7  -  IMPACT  OF  AUTOMATION 

QUESTION:  What  influence  will  the  growing  use  of  word  processing  have 

on  Technical  Manual  specifications  and  the  update  of  out-of- 
production  equipment  manuals? 

DIG. MISSION  HIGHLIGHTS:  Reference  was  made  to  the  recent  AIA  and  NSIA 
Symposia  on  automation.  The  term  "word  processing"  was 
quickly  modified  to  mean  "text  processing",  "graphic  processing 
and  "integrated  text  and  graphic  processing".  With  very  few 
exceptions  (NARF,  Jacksonville's  THUMP,  NSWSES's  ADREP's) 
surprisingly  little  influence  has  been  felt  to  date.  Recent 
advances  in  OCR  capability  were  used  to  show  that  the  potential 
is  ever  increasing  and  that  we  should  expect  major  influence 


in  the  relatively  near  future.  A  word  of  caution  was 
sounded  in  the  discussion  that  only  one  source  can  be 
u3ed  at  a  time  to  assure  configuration  control  of 
technical  manual  change. 

RESOLUTION:  ADPA  will  continue  to  encourage  participation  in  AIA 
and  N3IA  Symposia  and  will  not  parallel  the  very  fine 
efforts  of  these  organizations.  ADPA  will  continue  to 
provide  a  sounding  board  via  workshops  to  examine  trends 
and  influences.  Look  for  restrictive  use  of  photographic 
coverage  in  Technical  Manuals  brought  about  by  increased 
use  of  digitized  line  artwork. 

WORKSHOP  ISSUE  8  -  MIL-M-38784A  LETTERING  SIZE  REQUIREMENT 

PROBLEM:  MIL-M-38784A  calls  for  8  (min)  to  10  (max)  point  character 
size  on  illustrations.  This  requirement  is  ambiguous  and 
interpreted  differently  by  various  customers.  A  change 
notice  to  this  specification  is  required  to  clarify  this 
point. 

DISCUSSION  HIGHLIGHTS:  Discussion  brought  out  that  somewhere  in  the 

translation  of  the  older  5474  specification,  the  requirement 
was  refined  from  "80  letters"  to  "8  point".  Using  "80  letters 
is  a  safe  approach  to  insure  legibility  and  spec  compliance. 
Using  the  "8  point"  requirement  could  be  troublesome  if  the 
interpretation  is  that  "80  letters"  was  intended.  This  issue 
should  be  brought  to  the  attention  of  the  TMS3  Program  for 
action. 

FOLLOW-UP  ACTION:  ADPA  will  address  this  problem  to  the  TOSS  Program 
office  at  the  earliest  opportunity. 


WORKSHOP  ISSUE  9  -  SPECIFICATIONS  FOR  "LESS  THAN  WEAPON  SYSTEMS" 


PR03LEM:  It  is  difficult  to  prepare  comprehensive  and  well  organized 

Technical  Manuals  due  to  restrictive  requirements  of 
MIL-M-15071G  (US  Navy).  This  Technical  Manual  specification 
is  directed  toward  more  generalized  and  standardized  mil-specs. 

DISCUSSION  HIGHLIGHTS:  There  were  two  distinct  rounds  to  the  discussion 
of  this  problem.  The  first  round  led  to  the  conclusion  that 
much  could  be  dona  within  the  existing  framework  of  tailoring 
to  achieve  the  desired  approach.  Aegis  was  cited  as  an  ideal 
example  of  how  an  enlightened  program  office  in  the  service 
organization  could  both  encourage  and  implement  innovation. 

It  wasn't  until  the  discussion  reached  a  much  different 
second  round  that  the  workshop  participants  appreciated  that 
this  was  the  plea  of  a  contractor  involved  in  "less  than 
weapon  system"  equipment.  Both  the  specification  requirements 
and  lack  of  communication  channels  to  resolve  interpretation 
were  then  brought  out  as  areas  needing  attention.  It  was 
determined  that  a  study  of  this  acquisition  area  was  nee led. 

FOLLOW-UP  ACTION:  ADPA  will  encourage  the  TM3S  Program  to  include  this 
issue  in  one  of  the  future  discussions.  ADPA  will  encourage 
a  study  of  this  problem  to  ensure  that  adequate  focus  is 
provided  to  "less  than  weapon  systems"  Technical  Manual 
coverage. 

RECOGNITION:  Special  thanks  are  in  order  for  the  excellent  setting 

provided  by  the  Naval  Postgraduate  School,  Monterey,  Calif ornia. 

Also,  the  attendance  and  active  participation  of  R.  D.  Kemp, 
Maj.  L.  Nesbitt,  and  S.  L.  Simmons  did  much  to  achieve  the 
conmuni cation  level  that  was  realized.  Although  not 
established  as  a  formal  panel,  these  men  formed  the  backbone 
of  the  workshop  session. 


WORKSHOP  #5 

ILS/TECHNICAL  FJBLICATIONS 
ROSTER 


Name 

Richard  E.  Knob 

R.  Leon  Snodgrass 
David  Blackstone 
Gaiy  L.  Blackly 
Bill  Brossman 

E.  A.  Woodward 
E.  C.  Lacz 

K.  E.  Radcliff 
Rodger  Wilson 

S.  L.  Simmons 
J.  F.  Courtney 

L.  L.  Glowienka 
Maj.  L.  Nesbitt 
R.  D.  Kemp 

Lt.Col.  (Rtd)  R.  D.  French 

B.  J.  Bretz 

C.  D.  Fisher 


Affiliation 

Sperry  Gyroscope 
EG&G,  Inc. 

Ingersoll-Rand  Co. 

Ford  Aerospace 
AVCO-LYCOMING 
Honeywell 
NAVSEA  PMS400F35 
NSWSES  (NSDS  A) 

FMC  Corp. ,  Northern  ORD. 
NSWSES  (5130) 

Vought  Corporation 
Ken  Cook  Company 
AFALD/PTQS 
RCA 

Min.  of  Defence  (UK) 

U.S.  Army  MERADCOM 
RCA 


METRICATION  OP  TECHNICAL  DOCUMENTATION 
JACK  L.  WILSON 

Chairman,  California  Metrication  Committee 


NOTE:  This  paper  was  transcribed  from 
a  recording  of  the  session. 


Happiness  was  described  a  few  minutes  ago  as  having  a  full  tank  of 
gas.  That  being  the  case,  maybe  unhappiness  is  leaving  home  with 
something  less  than  a  full  tank  of  gas  and  having  to  drive  350 
kilometers  on  an  odd  day  with  even  license  plates. 


I  was  somewhat  overjoyed  at  being  asked  to  address  this  session. 
Contrary  to  ordinary  belief,  I  am  not  a  charter  member  of  ADPA; 
however  I  have  been  a  life  member  for  a  very  long  time.  I  am  not 
a  stranger  to  this  organization. 


Several  years  ago  I  made  a  study  of  my  own  company  as  to  specif ica 
tions,  standards,  and  other  professional  documents  that  would  be 
affected  by  implementing  the  metric  system  of  units.  When  the 
total  came  to  something  around  900,000,  I  quit,  but  what  we  are 
talking  about  is  something  that  is  really  not  strange — it  is  some¬ 
thing  that  is  more  frightening. 


I  would  like  to  lay  the  groundwork  a  little  bit  here.  I  am  remind 
ed  of  a  story.  I  don't  know  why  I  should  be  reminded  of  it;  it's 
a  Navy  story.  It  seems  that  this  midshipman  back  in  the  Naval 
Academy  was  asked  to  give  a  briefing  on  an  engineering  problem  to 
a  group  of  staff  officers.  When  he  walked  into  the  lecture  room, 
he  looked  around  and  had  never  seen  as  much  gold  braid  in  all  his 
life.  So  with  typical  aplomb  which  they  teach  at  the  academy,  he 
said,  "I  am  sure  there  are  one  or  two  people  that  know  more  about 
this  subject  than  I  do,  but  I  don't  see  either  one  of  them  in  the 
audience . " 


I  can't  say  that  here.  I  look  around  here  and  I  see  quite  a  few 
people  in  this  audience  whom  I  know  know  more  about  this  subject 
than  I  do,  but  I  have  the  advantage.  I  am  up  here;  you  are  down 
there.  So  let's  start  from  the  beginning. 

When  we  start  talking  about  making  changes,  particularly  changes 
in  systems  of  units,  people  begin  to  panic.  All  of  a  sudden 
engineering  drawings  don't  look  the  same.  People  begin  to  worry. 
Things  don't  appear  as  they  should.  Everybody  says  you  can't  do 
it.  They  might  be  right,  I  don't  know.  Nothing  goes  right.  Even 
for  the  "do-it-yourselfers",  things  go  wrong.  But  when  we  talk 
about  implementing  metric  units  into  technical  documentation,  it 
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seems  like  things  go  dark.  It  seems  like  things  get  puzzled. 
(Indistinguishable  masses  of  light  and  dark  were  projected  onto 
the  screen.  They  vaguely  resembled  an  igloo  in  a  snow  storm.)  I 
am  going  to  go  back  to  this  particular  slide  a  little  later  on 
because  it  is  one  of  my  favorites. 

But  when  we  talk  about  implementing  the  metric  system  of  units, 
the  thing  that  bothers  most  people  is  that  they  have  been  taught 
to  think  "big".  What  do  we  mean  by  thinking  "big"  in  implement¬ 
ing  metric  units?  Well,  let's  take  an  example.  This  is  not  an 
example  of  a  problem  with  technical  documentation,  but  it  is 
typical  of  the  kinds  of  problems  which  can  occur  in  technical 
documentation.  This  situation  involves  a  can  of  macadamia  nuts 
from  Hawaii.  It  is  clearly  identified  as  having  a  weight  of 
sixteen  ounces,  or  one  pound,  and  then  comes  the  clincher,  the 
453.59  grams.  That's  all  well  and  good;  however  to  be  exact,  they 
really  should  have  said  that  it  was  453.59  and  3/7  grams.  Then 
that  one  pound  would  be  exact.  However,  when  I  sent  the  can  of 
macadamia  nuts  to  my  laboratory  and  actually  weighed  the  con¬ 
tents,  it  was  not  453.59  grams,  but  was  427.37  grams.  Now  let  me 
tell  you  why: 

Five  significant  figures  indicate  an  accuracy  of  the  one  pound  to 
at  least  four  places.  Macadamia  nuts  are  not  packaged  by  mass, 
they  are  packaged  by  count.  An  average  number  of  macadamia  nuts 
weighs  approximately  one  pound.  The  intent  was  not  the  mass  as 
indicated  by  the  "net  weight"  (as  it  is  called).  That  package,  if 
you  were  to  measure  it,  is  almost  exactly  ten  centimetres  on  a 
side.  It  has  a  volume  of  1000  cubic  centimetres  or  one  cubic  deci¬ 
metre  or,  by  the  grace  of  the  General  Conference  of  Weights  and 
Measures,  a  special  name  for  that  is  one  litre.  What  is  intended 
in  that  package  is  that  approximately  one  pound  of  macadamia  nuts 
occupies  a  volume  of  one  litre.  Now  that  is  not  evident  from  the 
labeling,  and  that  is  the  problem  with  much  of  the  metrication  in 
technical  documentation —  it  fails  to  say  what  it  means. 

Now  let  me  give  you  some  additional  examples.  This  is  the  name¬ 
plate  of  of  a  vacuum  pump  that  is  on  the  market  today,  an  excel¬ 
lent  pump,  by  the  way,  if  you  ignore  what  it  says  here.  The 
twenty-five  litres  a  metre  ("25  L/m”)  is  meaningless.  What  they 
meant  was  twenty-five  litres  per  minute  (25  L/min),  but  they 
didn't  use  the  proper  symbology.  Symbology  is  the  secret  of 
metric  implementation. 

Let's  go  on.  Let's  sec  what  happens  when  we  take  very  common 
things  and  we  convert  them  to  metric  units — conversion  is  the 
problem. 

The  Golden  Gate  Bridge  which  spans  the  entrance  to  San  Francisco 
Harbor  is  a  beautiful  structure,  but  let  me  tell  you  what  it 
stands  for  when  its  dimensions  are  given  metrically.  For  example, 
on  a  cold  day  due  to  the  contraction  of  the  cables,  the  center  of 
the  center  span  will  lift  1.5  metres.  On  a  hot  day,  it  will  sag 
three  metres.  On  a  normal  windy  day  the  center  of  the  center  span 
may  sway  as  much  as  eight  metres.  Now  those  of  you  who  have 
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driven  across  the  Golden  Gate  Bridge  on  a  windy  day  in  a  snail  car 
know  that  it  is  not  uncommon  to  be  notified  that  small  car  warn¬ 
ings  are  posted — your  car  can  change  lanes  without  even  trying. 
Driving  across  that  bridge  on  a  windy  day  is  just  like  crabbing  an 
aircraft  or  boat  into  the  wind;  it  is  not  an  easy  chore.  But  the 
important  thing  about  that  bridge  is  that  from  the  center  of  the 
center  span,  the  surface  of  the  water  at  mean  low  tide  is  a  little 
over  67  metres.  Now,  what  that  means  is  that  a  couple  of  the  sail¬ 
ing  ships  that  came  into  San  Francisco  around  the  turn  of  the  cen¬ 
tury  could  not  have  passed  under  that  bridge.  One  of  these  ships 
happens  to  have  had  a  height  from  the  top  of  the  main  mast  to  the 
waterline  of  a  little  over  90  metres  (296  feet).  A  second  one  was 
78.9  metres  high.  Even  these  early  ships  couldn't  pass  under 
there. 

The  aircraft  carrier  USS  Enterprise  has  some  excellent  character¬ 
istics,  but  the  height  from  the  waterline  to  the  top  of  the  super¬ 
structure  is  a  little  over  69  metres.  That  means  that  the  Enter¬ 
prise  cannot  come  under  the  Golden  Gate  Bridge  even  at  mean  low 
tide.  That  proved  embarrassing  to  the  Navy  because  the  Enter¬ 
prise  happens  to  be  stationed  at  the  Alameda  Air  Station  which  is 
inside  San  Francisco  Harbor.  In  fact,  not  only  does  the  Enter¬ 
prise  have  to  come  under  the  Golden  Gate  Bridge,  it  also  has  to 
make  a  90  degree  right  and  go  on  to  the  Bay  Bridge.  The  Bay 
Bridge  also  has  a  design  specifications  of  67  metres  from  the 
bottom  of  the  center  span  of  the  incoming  lane  to  the  surface  of 
the  water  at  mean  low  tide.  All  right  now,  how  do  we  get  the 
Enterprise  into  the  harbor? 

Well,  I've  made  several  telephone  calls  to  the  Naval  District 
Headquarters  in  San  Francisco  and  I  called  BuShips  in  Washington 
and  a  few  other  places.  The  answers  I  got  ranged  from  "Very 
carefully",  "We  select  the  conditions  under  which  we  do  it",  "I 
frankly  don't  know",  to  "If  you  really  want  to  know  why  don't  you 
wait  until  the  Enterprise  is  in  the  Air  Station  and  call  the 
Captain?  He  will  tell  you." 

Well,  being  a  little  bit  chagrined  about  this  time,  I  waited  until 
the  Enterprise  came  into  the  Air  Station,  but  I  didn't  go  down  and 
ask  the  Captain.  My  son,  who  is  an  officer  in  the  Civil  Air 
Patrol,  was  taking  his  squadron  on  a  tour  of  this  ship.  I  told 
him  to  ask  one  of  the  Engineering  Officers  how  they  get  that  big 
ship  under  these  bridges?  Without  a  moment's  hestitation,  the 
Engineering  Officer  said,  "It  is  quite  simple--we  pump  all  of  the 
ballast  from  port  to  starboard,  which  causes  the  ship  to  list 
slightly  over  7-12  degrees.  This  enables  us  to  clear  the 
bridge."  Anyone  who  believes  that  will  believe  anything. 

What  actually  happens  is  that  part  of  the  superstructure  is  lower¬ 
ed  and  part  of  it  lays  back  so  that,  with  care,  it  will  come  under 
the  bridges.  The  total  height  then  is  something  less  than  67 
metres.  Furthermore,  the  difference  between  the  "as-designed"  and 
"as-built"  conf iguration  of  the  bridge  is  such  that  there  is 
actually  almost  70  metres  from  the  bottom  of  the  span  to  the  sur¬ 
face  of  the  water  at  mean  low  tide. 
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Just  like  in  the  manufacturing  industry,  in  spite  of  all  of  the 
specifications  and  standards  that  made  up  the  engineering,  the 
final  emphasis  is  to  hammer,  saw,  and  file  to  fit  in  the  assembly. 
In  the  marine  and  shipbuilding  industry,  they  phrase  it  another 
way:  "Heat  and  beat  to  meet".  And  just  to  show  that  the  Air 
Force  is  not  immune,  their  phrase  is  "We  measure  it 
with  a  caliper,  mark  it  with  a  pen,  and  cut  it  with  an  axe." 

Now  what  is  the  problem  with  metricating  technical  documentation? 
The  problem  is  fear  of  the  unknown.  There  is  nothing  strange 
about  it.  All  you  have  to  do  is  remember  a  few  salient  rules.  The 
rules  are  symbology,  the  correct  system,  and  the  proper  applica¬ 
tion. 

Let's  look  at  this  picture  again  (the  igloo  in  a  snow  storm?). 

Is  there  anybody  that  hasn't  figured  it  out  by  now?  That  big 
black  blob  is  an  ear  and  that  big  black  blob  is  an  ear.  That  is  an 
eye,  that  is  an  eye,  and  that  is  a  nose.  (Immediately  a  clearly 
discernable  picture  of  a  Jersey  cow  emerged  from  the  gray  masses.) 
Once  you  have  stopped  to  take  a  good  long,  hard  look  at  a  metricat- 
ed  technical  document,  you  have  your  sacred  cow  right  back  with 
you. 

Technical  documenation  simply  means  presenting  in  technical  terms 
a  description  of  something.  It  may  be  written,  it  may  be  verbal, 
it  may  be  graphical,  or  it  may  be  pictorial.  But  we  are  describ-. 
ing  something  in  technical  terms.  Technical  documentation  must  be 
correct,  it  must  be  factual,  it  must  be  realistic,  and  must  be 
understandable  by  those  who  need  to  understand.  Correct  usage  of 
SI  metric  units  is  essential. 

I  have  to  mention  I  am  the  Chairman  of  one  of  the  ANSI  Standards 
Committees.  I  have  written  standards  and  specifications  for  over 
twenty-five  years.  It  is  not  easy.  I  have  also  used  systems  of 
measure  for  a  considerably  longer  period  of  time. 

I  have  here  a  little  document  called  "Pressure  Conversion  Factors" 
which  is  published  by  a  manufacturing  concern.  In  addition  to  the 
common  systems  of  pressure  (pounds  per  square  inch),  this  booklet 
contains  twenty-five  conversion  factors  for  other  units  designating 
the  same  thing.  In  the  new  scheme  of  things,  only  one  of  the 
twenty-five  units  is  correct;  that  is  the  pascal.  This  booklet 
even  misspells  "pascal".  In  implementing  the  SI  metric  units,  we 
must  be  careful  to  avoid  being  misled  by  such  publications. 

I  am  talking  about  the  implementation  of  a  single  system  of  units, 
the  International  System  of  Units,  officially  abbreviated  "SI"  in 
all  of  the  languages  of  the  world.  It  is  an  outgrowth  of  one  of 
the  organizations  set  up  by  the  International  Treaty  of  the  Metre. 
It  is  the  only  metric  system  that  will  remain  in  existence  in  the 
future.  It  is  the  one  form  to  which  many  metric  nations  of  the 
world  are  voluntarily  changing.  It  has  many  advantages.  It  is 
truly  an  international  system.  It  is  not  a  system  that  can  be 
unilaterally  changed  by  any  one  of  the  nations,  despite  the 
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wording  in  the  Metric  Conversion  Act  of  1975  in  the  United  States 
which  stated  that  the  system  of  units  referred  to  by  that  law  was 
the  International  Systems  of  Units  as  interpreted  and/or  modified 
by  the  Secretary  of  Commerce. 

There  have  been  several  recommendations  made  by  our  U.S.  represen¬ 
tatives  to  the  international  committees.  Some  have  been  accept¬ 
ed.  Some  have  yet  to  be  worked  on.  For  example,  I  mentioned  the 
litre  deliberately  because  it  has  been  decided  that  capital  *L" 
will  be  used  as  the  symbol  for  litre  in  this  country.  That  symbol 
has  not  been  accepted  by  the  General  Council  of  Weights  and  Mea¬ 
sures.  It  has  been  accepted  by  the  International  Committee  of 
Weights  and  Measures  and  will  be  submitted  to  the  General  Council 
of  Weights  and  Measures  at  the  next  meeting.  Officially,  today, 
and  since  1960,  the  symbol  for  "Litre"  is  small  "1"  and  if  there 
is  a  chance  for  confusion  between  that  and  the  number  one,  then 
you  spell  the  word  out.  In  fact,  that  is  one  of  the  cardinal 
rules  in  implementing  the  International  System  of  Units — when  in 
doubt,  spell  it  out.  Do  not  use  wrong  symbology;  do  not  select 
your  own  symbology. 

The  International  Committee  of  Weights  and  Measures  (the  United 
States  is  a  member  of  that  committee)  has  agreed  to  accept  the 
standards  published  by  the  International  Organization  for  Standar¬ 
dization  (ISO)  Technical  Committee  Twelve  (TC12).  There  is  a  full 
set  of  standards  on  the  units  to  be  used  and  on  how  they  should  be 
used. 

We  have  a  unique  situation  existing  in  the  United  States  in  that 
we  have  two  metric  practice  documents  designated  as  the  national 
standard  by  the  American  National  Standard  Institute.  These 
documents  are  written  by  two  different  professional  organizations. 
This  is  a  first  and,  hopefully,  will  be  a  last.  Hpefully,  it  will 
be  corrected.  The  difference  between  the  two  documents  is  stupid. 
It  is  how  to  spell  metre  and  litre.  But  we  won't  get  into  that 
one  either. 

What  does  it  all  amount  to?  This  is  it:  the  United  States  is 
going  metric.  Despite  the  vocal  few  who  say  that  it  will  never 
happen,  it  is  really  their  last  great  act  of  defiance. 

Now  let  me  give  you  an  example.  When  I  say  we're  going  metric, 

I'm  not  saying  we  are  going  to  change  everything,  because  we  cer¬ 
tainly  aren't.  I  am  retiring  from  Sandia  later  on  this  summer  and 
moving  back  to  the  Midwest,  to  Indiana.  I  can  still  find  some 
old-timers  back  there  that  if  you  ask  them  how  far  it  is  to  a 
certain  place,  will  answer,  "Down  yonder  a  ways."  Now  think  about 
that  a  minute.  "Down  yonder"  is  a  very  positive,  definitive 
distance  to  them.  From  point  "A"  to  point  "B"  is  "down  yonder  a 
ways".  That  takes  into  consideration  the  gravitational  pull  of 
the  moon,  the  spin  of  the  earth,  the  tide,  the  wind,  the  time  of 
the  year,  and  everything  else.  There  are  no  tolerances  involved. 
It  is  a  fixed  distance.  You  go  far  enough  that  way  and  you  get 
there. 


You  go  over  to  Appalachia  and  they  even  have  a  more  definitive 
definition  of  distance  and  that  is  so  many  "hoots  and  hollers". 

Now  for  those  who  are  not  familiar  with  hoots  and  hollers,  it 
means  that  you  are  too  young  to  remember  prohibition  and  moon¬ 
shine.  When  the  flatlander  approached  the  hills  of  Appalachia, 
their  way  of  warning  the  moonshiners  that  someone  was  approaching 
was  to  hoot  like  an  owl  from  one  hill  to  next  across  the  hollow. 
That's  your  hoots  and  hollers. 

When  we  implement  the  metric  system  of  units,  we  are  not  changing 
"down  yonder  a  ways",  we  are  not  changing  so  many  "hoots  and 
hollers",  we  are  not  changing  things  that  don't  need  to  be 
changed.  We  are  merely  implementing  an  international  system  of 
units  in  places  where  international  units  need  to  be  used. 

Although  I  happen  to  be  concerned  primarily  with  quality  assurance 
and  quality  control,  I  am  not  totally  unfamiliar  with  technical 
documentation.  If  you  don't  use  proper  units  in  documentation — 
be  it  quality  assurance,  quality  control,  or  technical  documenta¬ 
tion — the  result  is  not  as  meaningful  as  you  intend  it  to  be. 

So,  we  are  going  metric  whether  you  want  to  or  not — be  prepared. 
And  I  am  going  back  to  Livermore  and  back  to  my  sick  bed.  I  hope 
to  find  some  kind  filling  station  in  Monterey  and  we  will  overlook 
the  fact  that  this  is  an  odd  day. 


Thank  you. 
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EXECUTIVE  SUMMARY 

This  paper  explains  how  one  military  contractor  utilized 
a  controlled  computer  data  base  as  the  "master"  for  engi¬ 
neering  parts  list  (PL)  data  to  eliminate  PL  hard  copy 
storage  and  microfilm  costs  from  its  technical  documenta¬ 
tion  operations.  The  paper  discusses  the  disciplines  and 
controls  necessary  to  utilize  a  computer  data  base  as  the 
"master"  for  engineering  technical  data.  It  also  defines 
the  enhancements  required  to  a  typical  Automated  Data  Pro¬ 
cessing  (ADP)  system  used  only  to  prepare  MIL-STD-100 
Parts  List  to  allow  its  data  base  to  be  a  master  for  the 
company's  engineering  parts  list  data. 


definition; 


PL  -  Parts  List  per  MIL-STD-100  prepared  with  Auto¬ 

mated  Data  Processing  (ADP)  methods.  See  PDS. 

ADP  -  Hardware/ Software  System  used  to  process  and 

prepare  data.  See  1100. 

PDS  -  Sperry  Univac  Product  Definition  Information 

System  (PDS)  operating  on  1100  Series  Computer, 
used  as  an  identification  data  base  and  to  pre¬ 
pare  engineering  parts  lists  per  MIL-STD-100. 

ACS  -  Sperry  Univac  Active  Change  Status  (ACS)  Infor¬ 

mation  System  operating  on  1100  Series  Computer, 
used  to  status  and  control  engineering  changes 
per  DOD-STD-480A,  MIL-STD-483  and  MIL-STD-482. 

1100  -  SPERRY  UNIVAcf®1100  Series  Data  Processing  (Com¬ 

puter)  System. 

UNISCOP^®  -  SPERRY  UNIVAC  display  terminal, 
terminal 

BACKGROUND 

Sperry  Univac  Defense  Systems  started  using  a  computer  to 
prepare  a  detached  engineering  parts  list  (PL)  in  1962.  From 
that  point  on,  it  continued  to  store  the  current  computer 
prepared  PL  in  an  engineering  vault  as  the  "master"  and  to 
microfilm  all  revisions  of  the  engineering  PL  for  history. 

In  the  fall  of  1977,  Sperry  Univac  stopped  storing  computer 
prepared  engineering  PL*  s  in  the  Technical  Documentation 
Center  (vault)  and  stopped  microfilming  of  the  engineering 
PL’s.  This  was  done  after  the  implementation  of  a  one  year 
technical  documentation  support  software  enhancement  project. 


DESCRIPTION  OF  FORMER  PL  SYSTEM 

Based  on  engineering  authorization  and  change  board  approval 
reflected  in  the  Active  Change  Status  (ACS)  Information  Sys¬ 
tem,  engineering  parts  list  data  was  input  to  the  Product 
Definition  Information  System  (PDS) .  The  PDS  System  then 
prepared  a  PL  hard  copy  master  which  was  checked,  micro¬ 
filmed  and  distributed  to  satellite  files  in  aperture  card 
format.  The  latest  PL  hard  copy  was  stored  in  the  Techni¬ 
cal  Documentation  Center  (vault)  as  the  "master"  and  a 
microfilm  history  file  was  maintained  of  each  PL  Revision. 

On  receipt  of  PL  hard  copy  "master"  in  the  vault  for  filing 
the  change  was  closed  out  in  the  ACS  System.  See  Figure  1 
for  flow  diagram. 


DESCRIPTION  OF  PRESENT  PL  SYSTEM 

Based  on  engineering  authorization  and  change  board  approval 
reflected  in  the  Active  Change  Status  (ACS)  Information  Sys¬ 
tem,  engineering  parts  list  data  is  input  to  the  Product 
Definition  Information  System  (PDS) .  The  PDS  System  verifies 
that  the  PL  change  has  been  approved  in  the  ACS  System.  The 
PDS  System  is  then  updated  and  change  data  is  stored  in  the 
data  base.  The  PDS  System  data  base  is  checked  against  the 
approved  engineering  change  and  the  change  is  then  closed 
out  in  the  ACS  System.  Disaster  tapes  are  maintained  for  all 
technical  data  in  the  PDS  System  data  base.  PL  data  is 
available  on  UNISCOPE  terminals  throughout  the  SPERRY  UNIVAC 
1100  network  in  various  tailored  formats.  PL  hard  copy  is 
available  in  UNISCOPE  terminal  format  at  any  UNISCOPE  terminal  printe 
PL  hard  copy  in  MIL-STD-100  format  at  any  desired  revision 
is  available  on  request.  The  PL  hard  copy  in  MIL-STD-100 
format  is  generated  on  high  speed  printers  at  the  Sperry 
Univac  facility  making  the  request.  See  Figure  2  for  flow 
diagram.  Figure  3  for  1100  network  and  Figure  4  for  typical 
PL  hard  copy  in  MIL-STD-100  format.  The  present  PL  System 
does  not  include  a  microfilm  on  a  PL  filing  task. 
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NECESSARY  DISCIPLINES  AND  CONTROLS 

The  following  disciplines  and  controls  need  to  be  in  operation 
to  install  the  computer  "master"  data  base  concept: 

1 .  Documented  change  data . 

2.  Engineering  Authorization  and  change  approval  status 
account ing. 

3.  Responsibility  for  data  integrity  assigned  to  each 
identified  document  in  data  base. 

4.  Effective  data  checking  function. 

5.  Effective  data  security  (disaster)  methods. 

6.  Effective  data  communication/distribution. 

An  ADP  System  can  not  overcome  deficiencies  in  the  above. 


ADP  ENHANCEMENTS 

Assuming  that  a  typical  ADP  System  is  in  operation  and  used 

to  prepare  MIL-STD-100  Parts  Lists,  the  following  software 

enhancements  are  required  to  use  the  ADP  System  data  base  as 

the  "master"  for  the  engineering  parts  list  data. 

1.  Software  verification  that  change  is  approved  prior  to 
update  of  data  base. 

2.  Storage  of  change  history  data  in  data  base  by  change 
approval  number. 

3.  Capability  to  prepare  engineering  PL  at  any  desired 
revision. 

4.  Identification  in  data  base  of  organization  and  location 
responsibility  for  data  base  integrity  by  document  number. 

5.  Input  data  software  validation  and  error  reporting  to 
responsible  organization  and  input  organization. 

6.  Disaster  backup  capability  for  data  base. 


CONCLUSION 

This  case  in  point  presentation  depicts  a  step  towards 
"true"  software  configuration  management.  Only  with  many 
more  steps  can  we  expect  to  realize  the  total  benefits  that 
automation  can  bring  to  the  world  of  Technical  Documentation 
Control.  We  can  not  afford  the  hard  copy  "master"  control 
method  for  technical  documentation  prepared  with  Automated 
Data  Processing  (ADP)  methods. 
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Computer  Aided  Design  and  Computer  Aided  Manufacturing  is  a  development  that 
has  literally  exploded  on  the  scene.  It  has  proven  to  be  a  natural  extension 
of  the  designer's  mind  as  the  hand-held  calculator  has  become  an  aide  to  the 
professional  accounting  ranks. 

Computer  design  graphics  is  a  technological  innovation  whose  time  has  come, 
but  two  factors  have  -speeded  up  the  process.  First,  engineers  are  not  as 
available  as  they  were  in  the  1960's,  Fewer  and  fewer  young  men  and  women 
have  chosen  an  engineering  profession.  Secondly,  the  price  of  computer 
hardware  has  been  plummeting  while  the  cost  of  scarce  engineering  talent 
has  been  escalating.  These  factors  have  made  design  graphics  exceedingly 
attractive  from  an  economic  viewpoint. . 

«• 

DESIGN  GRAPHICS  HARDWARE  SYSTEMS 

There  are  a  substantial  number  of  offerings  by  hardware  manufacturers  which 
will  satisfy  design  graphics  users.  Each  of  these  firms  have  different 
options,  software  packages,  etc.  available  for  general  design/drafting/ 
manufacturing  needs.  Also  some  of  the  units  fulfill  very  specific  design 
requirements.  This  especially  is  true  when  systems  with  complex  analysis 
abilities  are  considered.  In  addition  to  the  large  number  of  available  systems 
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many  companies,  and  in  particular  aerospace  companies,  have  developed  their 
own  brand  of  computer  graphics. 

Lockheed  Corporation  is  one  of  those  aerospace  companies  which  have 
developed  their  own  system.  It  is  marketed  by  IBM  and  is  called  CADAM 
(Computer  Augmented  Design  and  Manufacturing) .  CADAM  has  been  in  existence 
for  about  10  years.  Naturally,  as  with  all  technology,  CADAM  has  proceeded 
through  successive  stages  of  greater  technical  sophistication  and  versatility. 

As  an  employee  of  Lockheed  Missiles  and  Space  Company,  I  have  been  involved  with 
CADAM  for  a  number  of  years  and  really  have  a  somewhat  limited  expertise  with 
other  products.  It  is  not  necessary  to  this  presentation  for  a  hardware 
discussion  of  all  the  potential  graphic  systems,  since  we  are  going  to 
concentrate  on  the  documentation  aspects  of  the  peripherals.  These  documentat¬ 
ion  units  tend  to  have  very  similar  characteristics  in  all  systems  and  the 
following  discussions  will  not  be  greatly  influenced  by  the  hardware. 

CADAM  SYSTEM  HARDWARE 

It  is  necessary  to  briefly  describe  the  system  which  is  best  known  to  me  to 
understand  the  subsequent  documentation  process.  Figure  1  shows  a  typical 
CADAM  work  station.  The  system  is  highly  User  oriented  and  extremely 
responsive.  A  designer  uses  three  basic  devices  to  create  a  drawing.  The 
first  is  a  Function  Key  Board  which  is  used  to  select  points,  lines,  splines, 
certain  analyses,  etc.  The  Light  Pen  is  an  actuator  and  locator  for  those 
functions.  The  Typewriter  Keyboard  is  an  input  device  for  alphameric 
characters.  Bills  of  material  and  notes  are  examples  where  this  capability 


is  used . 
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Figure  2  is  a  pictorial  description  of  the  hardware  that  makes  up  a  typical 
Installation.  The  central  computer  is  an  IBM  370/365  which  in  turn  has 
coaxial  lines  running  to  controllers.  Long  distance  cable  runs  require  long 
line  adapters.  Each  controller  will  handle  2  work  stations  and  normally  4 
work  stations  are  placed  together  as  a  module.  A  high  speed  printer,  card 
reader,  magnetic  tape  unit  and  disk  storage  units  are  also  part  of  the  main 
CADAM  data  processing  system.  The  peripheral  documentation  generation  devices 
produce  numerical  control  punched  tapes,  microfilm,  x-y  plotter  drawings  and  hard 
copy. 

Figure  3  highlights  a  particular  microfilm  output  device.  In  this  case,  the 
unit  is  a  COMP  80  film  plotter.  A  CADAM  magnetic  tape  is  loaded  on  the  film 
plotter  each  night  and  ultimately  35mm  aperture  cards  are  produced  for 
distribution.  This  is  by  far  the  most  economic  method  of  generating  viable 
documentation  output.  If  hard  copy  is  required  in  areas  such  as  manufacturing, 
microfilm  printer-readers  are  readily  available. 

Figure  4  describes  the  Cal  Comp  7000  x-y  plotter.  This  device  is  an  ink  on 
paper/mylar  unit. 

The  plotter  is  in  reality  a  precision  drawing  system  capable  of  great 
accuracy  and  repeatability.  Line  widths  and  colors  can  be  varied  depending 
upon  the  output  requirements  and  use.  Loft  drawings  drawn  on  mylar  are  a 
perfect  example  of  a  quality  drawing  product  using  this  system.  The  plotters 
are  expensive  and  slow  compared  to  other  hard  copy  methods. 


FILM  PLOTTER  (COMP  80) 

* 


•  PRODUCES  HIGH  QUALITY,  HIGH  RESOLUTION  16  &35  MM  FILM 

•  CAN  DO: 

CONTINUOUS  STRIP  PLOTS  -  300  FRAMES/HR 
FORMS  GENERATION 
FRAME  ROTATION 

•  STRUCTURED  FOR  ADDITION  OF  MICROFICHE  CAMERA 


Figure  3 


X-Y  PLOTTER  (CAL  COMP  7000) 

•  PRECISION  DRAWING  SYSTEM 

•  LARGE  SIZE  HIGH  QUALITY  DRAWINGS 

•  RECOMMENDED  WHEN  HIGH  QUALITY  AND  ACCURACY  OR  LARGE  SIZE 

DRAWINGS  ARE  NEEDED 

•  MAX  DRAWING  SIZE -48  IN.  X  820  IN. 

ACCURACY -±0.005 
REPEATABILITY  -±0.002 

3  LINE  SIZES -LIGHT,  MEDIUM,  HEAVY 

4  COLORS -BLACK,  BLUE,  RED,  GREEN 


Figure  4 


COMPUTER  GRAPHICS  AND  ENGINEERING  DOCUMENTATION  -  continued 


A  device  such  as  an  x-y  plotter  is  almost  certainly  required  if  Class  I, 

Type  I  microfilm  is  required.  Ideally,  output  from  the  plotter  should  be 
generated  only  once  and  that  should  be  at  the  end  of  the  contract  or  at  the 
time  of  documentation  delivery. 

Figure  5  describes  a  hard  copy  output  device  which  is  primarily  used  for  an 
engineering  or  checking  output.  The  engineers  have  one  of  these  units  very 
close  to  the  design  station  and  can  periodically  pull  a  copy  to  determine 
and  analyze  his  progress.  Once  he  feels  his  design  is  completed,  copies  are 
produced  and  distributed  to  check  other  organizations  for  approval  authority. 

In  Lockheed,  we  are  presently  using  Versatec  units  which  generate  prints  in 
about  30  seconds.  Figure  6  shows  a  typical  unit  with  a  plot  which  uses  100 
points  to  the  inch.  Figure  7  shows  a  200  point  per  inch  plotter  output. 

Figure  8  highlights  the  functions  associated  with  the  numerical  control  aspects 
of  a  design  graphics  system. 

A  numeric  control  (NC)  programmer  develops  an  operational  sequence  which 
directs  a  machine  tool  (eg.  mill  cutter)  to  produce  a  part.  Since  the  NC 
programmer  and  the  designer  are  using  common  geometry  sub-processes,  the  number 
of  cut-and-try  patterns  are  greatly  reduced  and  sometimes  eliminated  all 
together.  NC  programs  within  most  systems  actually  show  the  cutter  path  on  the 
display  after  the  process  has  been  finished.  Editing  of  the  cutter  path  instruct 
ions  are  easy.  These  editing  and  verification  functions  reduce  time-spans  and 
labor  costs.  Importantly,  first-time  parts  have  lower  scrap  rates  and  tool 
set-up  times  improve. 


HIGH  SPEED  PLOTTER  (VERSATEC) 


•  ELECTROSTATIC,  DOT  MATRIX  DEVICE 

•  APPEARANCE 

•  PRIMARY  PURPOSE: 

PRELIMINARY  REVIEW  PRINTS 
CHECKPRINTS 
COORDINATION  COPIES 

•  TWO  SIZES 

11  INCH  BY  _ 

200  DOT/INCH 

36  INCH  BY _ 

100  DOT/INCH 

36  INCH  200  DOT/INCH  AVAILABLE 


Figure  5 


Fleure  8 


COMPUTER  GRAPHICS  AND  ENGINEERING  DOCUMENTATION  -  continued 


PARTS  LISTING 

Parts  listing  is  also  a  very  important  facet  of  the  entire  drawing  process. 

The  question  is  whether  it  should  be  done  manually  on  a  design  graphics 
system  or  generated  separate  parts  list  on  a  different  comper  system.  The 
proper  way  to  analyze  the  method  for  generation  of  parts  data  is  to  determine 
the  economic  trade-offs  available.  I  have  come  to  the  conclusion  that  separate 
parts  lists  should  be  used  wherever  possible.  This  is  especially  true  if  the 
separate  parts  list  is  computer  generated. 

The  reasoning  behind  this  decision  is  as  follows: 

o  Engineers  and  scientists  are  not  known  for  their  talents 
as  a  typist*  From  an  economic  point  of  view,  they  are 
slower  (less  productive) ,  and  more  expensive  than  a 
skilled  parts  lister  working  from  some  sort  of  input 
transmittal. 

o  Any  computer  design  graphics  system  is  inherently  expensive. 

Typing  out  a  parts  list  can  be  very  costly  and  temporarily 
removes  the  machine  out  of  the  design  stream.  In  other  words, 
don't  use  a  computer  graphics  system  as  a  typewriter  for 
integrated  bills  of  material  unless  your  Customer  insists. 

o  Finally,  no  design  graphics  system  that  I  am  aware  of  has  the 
sophistication  to  interface  with  inventory,  material  process¬ 
ing,  manufacturing  or  engineering  files.  This  is  the  area 
where  automated  parts  listing  pays  off.  Creation  of  purchase 
orders,  inventory  data,  etc.  would  be  non-existent  in  the 
present  day  operational  methods  of  such  systems. 
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COMPUTER  GRAPHICS  AND  ENGINEERING  DOCUMENTATION  -  continued 

DOCUMENTATION  FLOW 

The  documentation  flow  process  is  quite  different  for  each  company.  It  can 
be  even  different  for  Divisions  within  a  company.  For  purposes  of  this 
discussion,  Figure  9  represents  a  very  simplistic  model  of  a  typical  path 
for  an  engineering  drawing. 


At  the  beginning  of  the  design  task,  an  engineer  requests  a  drawing  number 
from  Data  Control.  In  turn.  Data  Control  gives  the  engineer  a  drawing  number, 
captures  pertinent  information  concerning  that  drawing  and  records  that 
information  into  a  computerized  drawing  tracking  system.  Next,  the  engineer 
creates  a  design  on  the  computer  graphics  system  and  prepares  a  bill  of  material 
transmittal  which  is  input  into  the  computer  system  by  Data  Control  personnel. 

Once  the  design  and  parts  list  has  been  completed,  the  engineer  obtains  the  desired 
quantity  of  hard  copy  prints.  These  are  distributed  to  the  checker  and  other 
Interested  individuals  who  are  in  the  drawing  approval  loop.  When  the  drawings 
are  determined  to  be  correct  and  adequate,  the  drawing  is  "signed".  This  is  where 
the  control  becomes  difficult  since  signatures  are  not  well  suited  for  design 
graphics  input  and  ultimate  drawing  control.  Ideally,  the  checker  space  on  the 
title  block  is  reserved  and  can  only  be  accessed  by  the  checker  using  a  password. 
The  password  described  on  Page  8,  opens  this  signature  block  to  alphameric 
entries.  The  identical  process  can  also  be  accomplished  for  safety,  product 
assurance.  Customer,  etc.  Once  assigned  in  the  computer  system,  the  drawing 
technically  released  is  available  for  use. 

Overnight  released  microfilm  is  created  and  distributed  to  all  interested 
agencies.  Data  Control  records  its  required  information  on  the  computer  system 
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DISTRIBUTION  LOCKED 


FOLLOWS 

PREVIOUS 

PROCESS 


SYSTEM 

LOCKED 


Figure  10 


DOCUMENTATION  PROTECTION 

•  SECURITY 

-  FILE  PROTECTION 

-  CLASSIFIED 

•  DATA  STORAGE 

•  DISASTER  FILES 


Figure  11 


COMPUTER  GRAPHICS  AND  ENGINEERING  DOCUMENTATION  -  continued 

easiest  and  most  economical  method.  Hard  copy  can  be  produced  from  magnetic 
tape  on  printers,  x-y  plotters  and  video  presentations  with  microfilm  aperture 
cards  generating  hard  copy.  Both  medias  are  excellent  to  maintain  drawing 
history. 

DISASTER  FILES 

Figure  10  shows  a  simple  flow  diagram  of  the  disaster  file  method  used  by 
my  firm  and  I  believe  it  is  somewhat  typical  throughout  the  industry.  The 
figure  is  quite  self-explanatory,  but  the  timing  is  important  and  deserves 
some  explanation. 

During  a  design  session,  the  engineer  "files"  his  drawing  about  every  10  or 
15  minutes.  This  action  protects  hi s  data  in  the  event  of  a  computer  failure 
which  could  wipe  out  his  information.  The  log  tape  captures  the  design  data 
for  processing  overnight .  This  is  also  the  magnetic  tape  which  is  placed 
in  the  library.  At  the  same  time,  active  drawings  or  work  in  process 
resides  on  the  disk  files.  At  the  end  of  the  month,  the  library  tapes  are  sent 
to  an  off-site  location.  These  are  known  as  the  "father"  tapes.  They 
represent  a  data  processing  compilation  of  the  previous  month's  work.  These 
data  replace  that  design  information  generated  during  the  previous  month 
which  are  now  referred  to  as  "grandfather"  tapes.  These  tapes  reside  in  a  vault 
area.  As  data  and  designs  become  inactive,  the  tapes  are  scratched  and 
recycled  for  further  use. 


COMPUTER  GRAPHICS  AND  ENGINEERING  DOCUMENTATION  -  continued 

The  above  file  protection  methods  are  basically  oriented  toward  proprietary 
data  control,  although  the  third  method  does  permit  close  monitoring  of 
classified  data.  For  proprietary  data,  the  "read  only"  mode  is  readily 
available  to  all  concerned  program  personnel.  This  is  not  necessarily  true 
for  classified  information. 

Speaking  of  classified  Information  on  computer  files,  we  must  examine  file 
protection  with  a  different  set  of  parameters.  Generally  speaking,  a  drawing 
or  a  small  number  of  drawings,  is  not  classified.  The  problem  of  security 
occurs  when  all  of  the  drawings  are  available  in  one  package.  This  is 
precisely  the  situation  when  a  complete  set  of  project  drawings  reside  on  a 
magnetic  tape  file  or  in  on-line  working  storage.  Communications  from  work 
stations  to  a  host  computer  also  pose  additional  security  problems. 

After  due  consideration,  it  appears  that  stand-alone  computer  design  graphics 
systems  have  the  greatest  Inherent  classified  protection.  Being  self 
contained,  with  its  own  documentation  output  devices,  and  in  special  constructed 
areas  automatically  prohibit  a  number  of  problems  from  occurring  with 
communications  and  document  handling.  This  combined  with  a  double  password 
system  lock  and  auditable  security  procedures  should  eliminate  the  usual 
classification  difficulties. 

DATA  STORAGE 

Economic  factors  and  the  operational  methods  of  a  Company  dictate  how,  when 
and  where  documentation  is  handled  and  stored.  From  a  strictly  design 
graphics  point  of  view,  microfilm  and  magnetic  tape  files  appear  to  be  the 


COMPUTER  GRAPHICS  AND  ENGINEERING  DOCUMENTATION  -  continued 


and  locks  down  the  system  to  prevent  further  change. 


DOCUMENTATION  PROTECTION 
SECURITY 

The  security,  both  proprietary  and  classified,  aspect  of  a  design  graphics 
system  is  a  serious  concern.  Everyone  has  heard  the  horror  stories  of 
unauthorized  individuals  violating  computer  files.  The  situation  with  design 
graphics  is  no  different.  In  a  typical  design  graphics  computer  system,  there 
are  or  can  be  three  methods  of  file  protection.  First  is  the  conventional  pass¬ 
word  technique  where  each  engineer,  checker,  etc.  has  his  own  unique  code  to 
allow  file  access.  It  is  important  that  treatment  of  the  password  carries  the 
same  importance  and  disciplinary  action  as  those  associated  with  security- 
type  (3  tumbler)  combination  locks.  Otherwise  design  personnel  will  be  "trading' 
passwords  thereby  destroying  the  file  protection. 

A  second  method  which  inhibits  unauthorized  file  access  is  a  log  tape. 
Effectively  this  tape  records  all  activity  during  a  given  day  which  allows 
a  reasonably  good  audit  trail. 

A  third,  and  usually  most  positive  method,  requires  both  an  operator's  password 
and  a  control  password  input  by  an  individual  who  oversees  the  given  area  of 
design  or  a  supervisor.  This  action  can  be  documented  by  requiring  a  sign-in/ 
sign-out  procedure  for  control  and  audit. 
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SUMMARY  OF  CHANGES  INCORPORATED  IN  DOD-STD-IOOC 
(supersedes  MIL-STD-100B) 

DOD-STD-IOOC 

DESCRIPTION  PARAGRAPH 

1.  The  following  IEEE  callouts  replaced  ANSI  designations  General 

with  no  technical  differences. 

IEEE  STD  91-1973  Graphic  Symbols  for  Logistic 

Diagrams  (Two-state  Devices). 

(Same  as  ANSI  Y32. 14-1973) 

IEEE  STD  200-1975  Reference  Designations  for 

Electrical  and  Electronics 
Parts  and  Equipment. 

(Same  as  ANSI  Y32. 16-1975) 

IEEE  STD  280-1967  Letter  Symbols  for  Quantities 

used  in  Electrical  Science 
and  Electrical  Engineering. 

(Same  as  ANSI  Y10. 5-1968) 

IEEE  STD  315-1975  Graphic  Symbols  for  Elec¬ 
trical  and  Electronics 
Diagrams  (including  Refer¬ 
ence  Designation  Class 
Designation  Letters). 

(Same  as  ANSI  Y32. 2-1975) 


2.  Scale  requirements  have  been  added.  They  are  101.1  &  106 

essentially  the  same  as  those  previously  contained  in 

MIL-STD-100A  except  a  straight  line  is  used  to  under¬ 
line  not-to-scale  dimensions. 

3.  Continuation  sheets  of  multisheet  drawings  prepared  101.1.1 

using  automated  preparation  techniques  need  not  be 

the  same  size  as  the  first  sheet  -  added. 

4.  Line  conventions  and  lettering  per  ANSI  Y14. 2-1979;  101.2* 

was  ANSI  Y14. 2-1973. 

ANSI  Y14.2M-1979  adds  standard  metric  line  widths 
and  lettering  heights;  allows  the  use  of  open  arrow¬ 
heads  and  a  single  line  width  for  all  lines  on  com- 
putered  prepared  drawings;  adopts  the  symmetry  and 
chain  lines  from  ISO/DIS  128.  (The  M  in  the  document 
number  indicates  the  standard  is  compatible  with 
metrication. ) 

5.  Provisions  for  using  isometric,  pictorial,  etc,  101.3.1 

views  -  added. 


Issue  dates  per  Applicable  Documents  listing. 


DESCRIPTION 


DOD-STD-IOOC 

PARAGRAPH 


6.  Application  of  the  metrics  system  in  new  designs  per  101.4.1 

DOD-STD-1476  -  added. 

DOD-STD-1476  provides  guidance  for  metrication,  includ¬ 
ing  use  of  existing  inch  items  in  new  metric  designs; 
defines  such  terms  as  "metric  design",  "soft-",  "hard- 
conversion";  requires  reidentification  of  hard  converted 
items  (considered  new  metric  items);  references  ASTM  E-380 
for  metric  units,  practices,  and  usage  (basically  SI  units). 

7.  Surface  texture,  waviness,  etc,  per  ANSI  B46. 1-1978;  was  101.6* 

ANSI  B46. 1-1962. 

ANSI  B46. 1-1978  covers  definitions,  method  of  measurement, 
etc,  for  both  customary  and  metric  units. 

8.  Surface  texture  symbols  per  ANSI  Y14. 36-1978  -  added.  101.6.1* 

ANSI  Y14. 36-1978  establishes  surface  texture  drafting 
practices  (generally  compatible  with  ISO  1302)  using 
either  customary  or  metric  units;  adds  symbols  for  indi¬ 
cating  "material  removal  by  machining  reguired/prohibited." 

(Error  in  Figure  2.) 


9.  Screw  thread  representation  per  ANSI  14.6-1978;  101.7* 

was  ANSI  Y14. 6-1957. 

ANSI  Y14. 6-1978  provides  improved  definition  for 
representing  screw  threads  on  drawings;  recommends 
simplified  representation  and  associated  designations; 
includes  only  a  minimum  of  related  design  information. 

.0.  Bevel  and  hypoid  gear  delineation  per  Y14. 7. 2-1978  -  101.8* 

added.  Y14. 7-1958  has  been  deleted. 


The  second  part  of  the  proposed  four  part  standard 
is  now  available.  (The  third  part  is  currently  being 
coordinated. ) 

LI.  Symbols  for  plumbing  fixtures  in  architecture  and  building  102.1.6.1* 
construction  per  Y32. 4-1977  -  added. 

L2.  Symbols  for  aircraft  hydraulic  and  pneumatic  systems  per  102.1.7.1* 

ANSI/SAE  AS1290  (July  1975)  -  added. 

L3.  Structual  symbols  per  MIL-STD-18  deleted.  (Document  102.1.8 

cancelled . ) 


L4.  Welding  symbols  per  ANSI/AWS  A2. 4-1976  and  terms  and  102.1.11* 

definitions  per  AWS  A3. 0-1976;  was  ANSI  Y32. 3-1969  and 
AWS  A3. 0-1969. 


‘  Issue  dates  per  Applicable  Documents  listing. 
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DESCRIPTION 

DOD-STD-IOOC 

PARAGRAPH 

15. 

Nondestructive  testing  symbols  per  ANSI/AWS  A2. 4-1976;  was 
ANSI  Y32. 17-1972. 

102.1.12* 

16. 

Letter  symbols  for 
ANSI  Y10. 19-1969. 

units  per  ANSI/IEEE  Std  260-1978;  was 

102.3.1* 

ANSI/IEEE  Std  260-1978  provides  symbols  for  used  when 
only  limited  character  sets  are  available  (e.g.,  all 
upper  or  lower  case  letters,  no  Greek  characters,  etc). 
(Conflicts  with  Method  2  contained  in  Table  8-1  of  ANSI 
Y14. 15-1966,  reaffirmed  1973,  which  covers  electronic 
diagrams. ) 

17. 

ANSI  Y14 . 15b-1973  - 

added. 

103.1* 

18. 

Printed  wiring  board  description  in  digital  form  per 

ANSI/I PC-D-3 50B  (August  1977)  -  added. 

103.3.1, 

201.9.8.1.1, 
6  201.9.9.1* 

19. 

Shopping  list  of  materials  for  drawing  originals,  dupli¬ 
cate  originals,  and  reproductions  -  added  as  follows: 

104 

SPECIFICATIONS 

Federal 

L-F-340 

Film,  Diazotype,  Sensitized,  Moist  and 
Dry  Process,  Roll  and  Sheet 

L-P-519 

Plastic  Sheet,  Tracing,  Glazed  Matte 

SPECIFICATION 

Federal 

UU-P-221 

Paper,  Direct-positive  Sensitized, 
(Diazotype-Moist  and  Dry  Process) 

UU-P-561 

Paper,  Tracing 

CCC-C-531 

Cloth,  Tracing 

Military 

MIL-D-5480 

Data,  Engineering  and  Technical 
Reproduction  Requirements  For 

MIL-D-8510 

Drawing,  Undimensioned,  Reproducibles, 
Photographic  and  Contact  Preparation 

Of  (ASG) 

MIL-M-38761 

Microfilm  and  Microfilm  Frame  Deck 

Used  for  Recording  Engineering 

Drawings  and  Associated  Data 

MIL-P-55010 

Plastic  Sheet,  Polyethylene 
Terephthalate 

These  document  are 
by  each  individual 

applicable  only  to  the  extent  specified 
contract. 

* 

Issue  dates  per  Applicable  Documents  listing. 
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DOD-STD-IOOC 

PARAGRAPH 


Restrictions  on  use  of  duplicate  drawing  originals  -  added. 

Requirement  that  all  drawings  pertaining  to  items  using 
radioactive  materials  be  marked  with  a  caution  note  - 
added . 

Provisions  for  continuing  columns  of  integral  parts  lists 
-  added.  Parts  list  format  requirements  clarified. 

New  note  required  on  printed  wiring  master  pattern 
drawings  which  must  be  on  stable  base  material  -  added. 

Layout  drawing  criteria  -  added. 

Numbering  of  associated  lists  clarified. 

Reidentification  of  non-interchangeable  parts  is  required 
up  to  and  including  the  assembly  where  interchangeability 
is  re-established  -  revision. 

Identification  requirements  for  bulk  materials  are 
clarified. 

Reference  to  DOD-D-IOOO  paragraph  3.8  on  contractor 
reference  documents  and  requirements  for  data  submittal  - 
added . 

Guidelines  for  use  of  latest  symbols,  abbreviations, 
drafting  practices,  etc  -  added. 

The  restriction  that  the  revision  block  be  blank  on  the 
initial  document  release  has  been  deleted. 

Location  of  revision  identif ication  on  multisheet  drawings 
clarified. 

The  requirement  for  new  approval/authentication  signatures 
on  redrawn  drawings  has  been  deleted. 

"Items  listed  on  a  subordinate  parts  list  or  reference 
document  are  not  repeated  in  using  assembly  parts  list 
unless  ..."  -  added. 

Design  activity  identification  is  now  a  mandatory  block  on 
all  associated  lists  (PL,  DL,  IL);  was  optional.  Require¬ 
ment  for  address  in  this  block  has  been  deleted. 

The  requirement  that  the  contract  number  be  entered  on  all 
sheets  of  associated  lists  has  been  deleted. 


"FSCM"  has  completely  replaced  "code  ident". 

The  term  "non-government  standards"  has  replaced 
■industry  standards". 


104.1 
107 

201.1.2 

201.9.8.1 

201.10 

402.8 

402.14, 
Cond  5 

402.16.4 

402.18 

502.3 

503.2 

505 

506 

601.1 

603.2.1 

604.3.1 

605.3.1 

603.2.2 

604.3.2 

605.3.2 

General 

General 
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ENGINEERING  TECHNICIAN 
COOE  70421 

CRANE  IN  47522 
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HQ.  UNITED  STATED  AIR 
CONFIGURATION  MANAGER 
WRIGHT-PATT  AFB  OH 


FORCE 

45431 


E  W  ANDERSON 

MARTIN  MARIETTA  AEROSPACE 
HAIL  STATION  G521C 
P  0  BOX  1681 

VANDERBERG  AFB  CA  93437 


WILLIAM  J  BECK 
HUGHES  AIRCRAFT  COMPANY 
1901  W  MALVERN  TC5/C100 
FULLERTON  CA  92634 


GERALD  R.  ANTHONY 

NAVAL  UNDERWATER  SYSTEMS  CTR. 

CODE  3622 

NEWPORT  R I  02840 


WALTER  BENDER 

NAVAL  UNDERWATER  SYSTEMS  CTR 
NEWPORT  R I  02840 


JOSEPH  F  ARMIJO 
TRACOR  INC 
1601  RESEARCH  BLVD 
ROCKVILLE  MD  20850 


HER3FRT  L  ATKINS 

EGCG  WASHINGTON  ANALYTICAL  SER 

2150  FIELDS  ROAD 

ROCKVILLE  MD  20850 


DIETER  W  BERGMAN 
IPC 

1727  HOWARD  ST 

EVANSTON  IL  60202 


ROY  BEYER 
FMC  CORPORATION 
•1105  COLEMAN  AVENUE 
SAN  JOSE  CA 


95108 


GARY  L  BLACHY 

FORD  AEROSPACE  £  COMM  CORP 
MGR  TECHNICAL  MANUALS  DEPT 
3939  FABIAN  WAY 
PALO  ALTO  CA  94303 


JAMES  M.  BLACK 
ASO/AEC 

WRIGHT-PATTERSON  AFB 
WRIGHT-PATT  AFB  OH  45324 


DAVID  G.  BLACKSTONE 
INGERSOLL  RAND  COMPANY 
SR.  TECH  WRITER 
HAMILTON  STREET 
PAINTED  POST  NY  14870 


KEN  BOLINE  #169-236 
JET  PROPULSION  LAB 
MGR  OF  C COM  PROJECT 
4800  OAK  GROVE  DRIVE 
PASAOENA  CA  9LI03 


ROBERT  L  BOOHER 
HQ  AIR  FORCE  LOGISTICS  COMMAM 
SUPV  SUPPLY  SYSTEMS  ANALYST 
HQ  AFLC/LOLCP 

WRIGHT-PATT  OH  45433 


GEORGE  L  BOYER 

USA  MSLE  MAT  £  READ  COMMAND 

CONFIGURATION  MGMENT  SPEC 

350  LOWELL  STREET 

ANDOVER  MA  01810 


ALVIN  BRAND 

RAYTHEON  COMPANY 

SENIOR  ENGINEER 

6380  HOLLISTER  AVENUE 

GOLETA  CA  93017 


BERNARD  J  BRETZ 

MERAOCOM 

DRDME-DE 

FT  BELVOIR  VA  22060 


WILLIAM  F  BROSSMAN 
AVCO  LYCOMING  DIVISION 
MGR  TECHNICAL  PUBLICATIONS 
550  SOUTH  MAIN  STREET 
STRATFORO  CT  06467 


LORNA  BURNS 
HUGHES  AIRCRAFT  CO 
BLDG  604  M/S  G244 
P  0  BOX  3310 
FULLERTON.  CA 


92634 


HARVEY  L.  COOK 
NORTHROP  CORPORATION 
CONFIGURATION  £  DATA  MGMENT 
3901  WEST  BROADWAY 
HAWTHORNE  CA  90250 


GP 


DAN  BURRS 
FMC  CORPORATION 
SR  STANDARDS  ENGINEER 
4800  EAST  RIVER  ROAD 
MINNEAPOLIS  MN  55421 


E  C  CALTA 

AEROJET  SERVICES  COMPANY 
CONFIGURATION  MANAGER 
P  0  BOX  13618*  BLDG  2001 
SACRAMENTO  CA  95813 


h 

h* 


JOHN  A  CAMPBELL 
MARTIN  MARIETTA  AEROSPACE 
MAIL  (TOP  0423 
P  0  BOX  279 

DENVER,  CO  80201 

ROBERT  H  CARRIER 
RAYTHEON  COMPANY 
EQUIPMENT  DEVELOPMENT  LAB 
BOSTON  POST  ROAD 


ea 


•v 

£ 


WAYLAND  MA 


01778 


ANDREW  D.  CERTO 

NAVAL  AIR  SYSTEMS  COMMAND 

CODE  516SB 

JEFFERSON  PLAZA  BLDG  #2 
WASHINGTON  DC  20361 


a 


ROBERT  CHENEY 
SANDERS  ASSOCIATES 
95  CANAL  ST.,  MS  NCA  5-3354 
NASHUA  NH  03061 


v. 

*  k 

wV 

S 


J  0  CLOSE 

BEECH  AIRCRAFT  CORP 
WICHITA  KS 


67202 


£ 


Z-3 


JOHN  C  COOPER 
ANCHOR  SOFTWARE  MGMT  LTD 
P  0  BOX  11046 
ALEXANDRIA  VA 


22312 


H.  K.  DECKER 

MCDUNNFLL  AIRCRAFT  COMPANY 
CONTRACT  SFRVICG  l  ADMIN  SYS. 


LOU  I' 


63166 


F  H  CORF ETT 
NOR  T  HRGP-DSD 
CONFIG/DATA  MNGR 
600  HICKS  ROAD 
ROLLING  MEADOWS  IL 


60194 


MR  DONALD  C  DtROSIA 
GENERAL  ELECTRIC  COMPANY 
I  RIVER  RUALi  3L0G  36-607 
SCHErNtCIADY  NY  12345 


GEORGE  M  COTTRILL 
BOEING  AEROSPACE  COMPANY 
P  0  DUX  3993 

SEATTLE  WA  93124 


STELLA  R  DESPAIN 
HQ  USAF 

DATA  MANAGEMENT  SPECIALIST 

USAF/aFSC/ VDTC/SD7G 

EGLIN  AFB  - L  32^42 


JOHN  F.  COURTNEY 
VUUGH  T  CORPORATION 
MGR.  TECH.  DATA  PLANS 
P.O.  BOX  2 ? 5907 
DALLAS  TX 


75265 


WILLIAM  0  9 1:  2  A  V  A  L  A 

VALU^  FNGIME-  RING  CJMRANY 

DFPT  MANAGE <  -  OXNARD  OFFICE 

3410  SOUTH  4  STREET 

OXNARO  CA  93030 


PAUL  T  COURTOGLJUS 
L  G  HANSCOM  AFC 
HU  ESU/TOSD 
BEDFORD  M A 


01730 


PAUL  H.  DIXON 

HARRIS  GOVERNMENT  "lEC  SYS  l 
GRP  MC-R.  OF  SO  DATA  1GMFNT 
P.H.  3DX  37 

MEL  BOURN c  FL  32^06 


THOMAS  F  COX 
MAIL  STATION  3150 
PO  bOX  177 
DENVFR  CO 


80201 


f  r.  dough;,  p.  r y  jr 

A A I  COR P 
P  0  BOX  6767 
BALTIMORE  -v:> 


21204 


teu  w .  coz ini- 

naval  AIR  ENGINEERING  CENTFR 
ENGINEERING  SPEC.  &  STDS.  DEPT 
LAKEHURST  NJ  08733 


REUBEN  E  DUNLAP 
US  ARM  i  MISSILE  CMD 
PRCPM-R Jl-C 
EGOS TONE  An  SNL  AL 


3  5  p  -  >9 


EDWARD  L  DEAN 
HUGHES  AIRCRAFT  COMPA  1Y 
CENT I  NFL  A  L  TEALE 
CULVER  CITY  CA  «0< 


JOHN  J.  DURANTE 

HO.  US  MARINE  CORPS 

MC-LMi;.  COMMONWEALTH  JHLOTNG 

1  30 0  WILSON  BOULEVARD 

ARLINGTON  VA  22?  )9 


j* IN  W  •  DEAN 

jf.HFS  AIRCRAFT  COMPANY 
.O.  BOX 
jllfrtun  CA 


«2  373 


SIO  EOF L ST F  IN 
17700  AVM.°N 
CARSON  CA 


90746 


ASA  EDENS 
GENERAL  DYNAMICS 
MIRADCOM  FLA  OFFICE  MZ44-55 
P  0  BOX  2507 

POMONA  CA  91766 


ALFRED  FISHER 
USAF/SAMSQ 

CONFIGURATION  MGR  SPECIALST 
P  0  BOX  92960 

LOS  ANGELES  CA  90009 


ANOREW  C  EDWARDE S *  JR 

USA  FIGHTING  VEHICLE  SYS  PROM 

Ct  CONF  MGT  OFC  FVS 

2023  LAUREL  DRIVE 

TROY  MI  48090 


MR  CHARLES  D  FISHER 
RCA 

BUILDING  10-6-2 

CAMDEN  NJ  08102 


RICHARD  A  EGBERT 
ROCKWELL  INTERNATIONAL 
CADMAT  PROJECT  MANAGER 
4300  EAST  FIFTH  AVENUE 
COLUMBUS  OH  43068 


LT  COL  WILLIAM  G  FOHRMAN 
U  S  AIR  FORCE  SYSTEMS  COMMAND 
CODE  AFD/AWZ 

WRIGHT-PATTERSON  AFB  OH  45433 


R  M  EGGAN 
TRW 

ONE  SPACE  PARK 
REDONDO  BEACH  CA 


90278 


MICHAEL  W  FONTAINE 

LITTON  INDUSTRIES  GtC  SYSTMS, 

GCC  SYSTEMS 

5500  CANOGA  AVENUE 

WOODLAND  HILLS  CA  91364 


CHARLES  J  EMBREY 
NORTHROP  SERVICES,  INC 
MGR  CONFIGURATION  MGMENT 
1700  NORTH  LYNN  STREET 
ARLINGTON  VA  22209 


KEITH  E  FOSTIR 

RAYTHEON  COMPANY 

C/DM  MANAGER 

HARTWELL  AVENUE 

BEDFORD  MA  01730 


LLOYD  E  ERVIN 
CORPUS  CHRISTI  ARMY  DEPOT 
BLDG  8  ATTN  SOSCC-Q 
CORPUS  CHRISTI  TX  78419 


J  L  FOX 

HUGHES  AIRCRAFT  COMPANY 
MANAGER,  ENGINEER  SERVICES 
FLORENCE  C  TEALE  STREETS 
CULVER  CITY  CA  90230 


VERNON  ESTES 

GENERAL  ELECTRIC  COMPANY 
MANAGER 

IRIVER  ROAD,  BLDG  IOA 
SCHENECTADY  NY  12345 


MYER  P  FELLERMAN 
TRW 

BLDG  M5  RM  0274 

ONE  SPACE  PARK 

REDONDO  BEACH  CA  90278 


MR  C  E  FRANKLIN 
SIKORSKY  AIRCRAFT 
STRATFORD  CT  06602 


LTCOL  R  D  FRENCH,  RET 
THE  3RITISH  EMBASSY 
3100  MASSACHUSETTS  AVEN'JE  NW 
W  ASH  I  NOT  ON  DC  200D8 


CAROLINE  FERNANDEZ 
GENERAL  DYANMICS  -  CONVAIR  OIV 
ENGINEERING  PRACTICES  ANALYST 
P  0  ROX  80847 

SAN  DIEGO  CA  92138 


Charles  a  fricke 

FORD  AEROSPACE  L  COMM  CORP 

3900  WELSH  ROAD 

WILLOW  GROVE  PA  19090 


Z-5 


t  * 


ROBERT  J.  GAMACHE 

NAVAL  UNDERWATER  SYSTEMS  CTR 

CODE  362202 

NEWPORT  RI  02840 


JOINT  TACTICAL  COMMUN.  OFFICES 

197  HANCE  AVENUE 

TINTON  FALLS  N.»  07724 


CHARLES  W  6EDNEY 
RAH  CORPORATION 
615  S  FREDERICK  AVE 
6AITHERSBUR6  HD 


20760 


H.A.  GRANDPHREY 
SPERRY  UNIVAC 
M/S  S1G01 
ST.  PAUL  MN 


55101 


RAYMOND  GEISICK 
aeronutronics-fgro 
ANTENNA  ENGR 
3939  FABIAN  WAY 
PALO  ALTO  CA 


94303 


GEORGE  A  GROVER 
LITTON  INDUSTRIES 
5500  CANOGA  AVENUE 
WOODLAND  HILLS  CA 


91365 


SUNOSTRAND  AVIATION  OPERATIONS 
CONFIGURATION  MGMT  SUPERVISOR 
4747  HARRISON  AVENUE 
ROCKFORD  IL  61101 


L.  J.  HAHN 
HONEYWELL «  INC. 

ENG.  DATA  ANALYST 

1625  ZARTHAN  AVE.  MN15-2596 

ST  LOUIS  PARK  MN  55416 


MR  LINUS  L  GLOWIENKA 

KEN  COOK  COMPANY 

9929  WEST  SILVER  SPRING  ROAO 

MILWAUKEE  WI  53225 


MARTINAMARIETTA  CORPORATION 
ENR.  CONTRACTS  DEPT. 

P.O.  BOX  179  M/S  2411 
DENVER  CO  80201 


CHARLES  F  GOESSLING 
U  S  MISSTLE  RESCH  £  DEV  CMMD 
REDSTONE  ARSNL  AL  35809 


JOHN  R  HART 
BOEING  AEROSPACE  CO 
P  0  BOX  3999  M/S  42-01 
SEATTLE  WA 


98124 


LOUIS  M  GOLORERG 

RAYTHEON  COMPANY 

CONFIGURATION  MANAGER 

350  LOWELL  STRFET 

ANOOVcR  MA  01810 


L  A  HARTMAN 
LOCKHEED 
1137  MYRTLE  DR 
SUNNYVALE  CA 


94086 


DONALD  S  GOLOFARB 
L0CKHEE0-CAL1 FORNI A  CO. 
CHIEF  DRAFTSMAN  o/<^  , 

BOX  551  0/70-10  B/ 80  P/A-l 
BURBANK  CA  91520 


WSlw  Hi"  hat  aw  cmd 

TECH  DATA  SUPERVISOR 

CODE  ORSEL-MS-TD 

FORT  MONMOUTH  NJ  07703 


THEODORE  L  GOLMIS 
HUGHES  AIRCRAFT  CO 
BLDG  604  M/S  FI 22 
P  0  BOX  3310 
FULLERTON  CA 


92634 


mSrTINBMARIETTA  CORPORATION 
P.O.  .3 OX  5937  MP- 131  ss 
ORLANDO  FL  32855 


Ca'.V'lVVa'j 


T.T.  HARRISON 

US  ARMY  MISSILE  RGD  COMMAND 
DATA  MANAGEMENT  SPECIALIST 
DROMI-ESD 

REDSTONE  ARSNL  AL  35809 


WILLIAM  J  HEIM 

US  NAVY 

524  S  ALVORD 

RIDGECREST  CA  93555 


THOMAS  J  HENDERSON 

FORD  AEROSPACE  L  COMM  CORP 

WDL  DIVISION 

3939  FABIAN  WAY  MS  H45 

PALO  ALTO  CA  ^4303 


ED  HOGAN 

CUBIC  CORPORATION 
TECHNICAL  SPECIALIST 
9233  BALBOA  AVENUE 
SAN  DIEGO  CA  92138 


MELVIN  J  IVERSON 

CUBIC  CORP 

9233  BALBOA  AVE 

SAN  DIEGO  CA  92123 


0  R  JACKSON 

WESTINGHOUSE  ELECTRIC  CORP 
ENGINEERING  SUPER 
HENOY  AVENUE 

SUNNYVALF  CA  94088 


GEORGE  M  JAMES 
ESL  »  INCORPORATED 
SUPERVISOR  DATA  MANAGEMENT 
495  JAVA  DRIVE 
SUNNYVALE  CA  94086 


RAYMOND  L  JONES 
NAVAL  EOO  FACILITY 
MECHANICAL  ENGINEERING  TECH 
INDIAN  HEAD  MD  20640 


GEORGE  E  HOGAN 

EMC  CORPORATION,  OFD 

SUPV  CONFIGURATION  CONTROL 

1105  COLEMAN  AVENUE 

SAN  JOSE  CA  95108 


FRANK  G  HOLMFS 

TRW  OSSG/MGMT  SYSTEMS 

ONF  SPACE  PARK 

REDONDO  BEACH  CA  90273 


GEORGE  J.  HROMNAK 
HQ.  ARRADCOMN,  DEPT.  OF  ARMY 
CH.  TECH.  DATA  CONFIG  MGMT  01' 
DRDAR'TST 

DOVER  NJ  07801 


EMIL  HRYSHKANYCH 
RDCE 

US  AMKY  ELECTRONICS  COMMAND 
FORT  MONMOUTH  NJ  07703 


GLENDA  HUGHES 

FORD  AEROSPACE  L  COMMUC AN  I TI ON 
CORPORATION 
3939  FA3IAN  WAY 
DALQ  ALTO  CA 


94303 


CHARLES  W.  JONES,  JR. 

HARRY  DIAMOND  LABORATORIES 
ENGINEERING  TECHNICIAN 
2800  POWDER E  MILL  ROAD 
ADELPHI  MD  20783 


ROBERT  B.  JORDAN 
USATARCOM 

MECHANICAL  ENGINEER  TECHNICHAI 
WARREN  MI  48090 


L  W  JULIAN 

WESTINGHOUSE  ELECTRIC  CORP 
HENDY  AVE 

SUNNYVALE  CA  94088 


STEPHEN  C  KAPERNAROS 
TRW 

ONE  SPACE  PARK 

REDONDO  PEACH  CA  90278 


SSPO 


EDWARD  E  KAWAHARA 
NAVAL  PLANT  REP  OFFICE 
CHIEF  ENGINEER 
0  D  n<JX  504 
SUNNYVALE  CA  95050 


R  D  KEMP 

RCA  MAIL  CODE  108-113 
MOORESTOWN  NJ 


08057 


HOWARD  LA  MUSKA 

3650  EMERALD  STREET  Y-l 

TORRANCE  CA  90503 


S3 

I 


JOHN  KICAK 
US  ARMY  OARCOM 
2804  KING  ST 
ALEXANDRIA  VA 


DONALO  KIEVET 

E-SYSTEMS 

ST.  PETERSBURG  EL 


22302 


33733 


JOHN  F  KILGALLON 

NAVAL  UNOERWATER  SYSTEMS  CNTR 

NEWPORT  RI  02840 


ROSS  G  KISTLER 

VITRO  LABORATORIES 

GROUP  SUPERVISOR  ENGINEER 

1400  GFGRGIA  AVENUE 

SILVER  SPRING  MD  20910 


MICHAEL  KOVAL ICK 
MARTIN  MARIETTA  CORPORATION 
M ICHOUO  OPERATIONS 
P  O  BOX  29304 
NEW  ORLEANS  LA 


RICHARD  E  KNOB 
SPERRY  RAND  CORP 
3311  AUSTIN  AVENUE 
WANTAGH  NY 


701  <39 


11793 


ERtu  KRAHNER 
BOEING 

DATA  COORDINATOR 
10630  -27TH  AVENUE  SW 
SEATTLE  WA  98146 


RALPH  J  LEFAVER,  JR 
’ ACIF IC  MISSILE  JEST  CENTER 
IEAD  MANAGEMENT  SUPPORT  ER 
20INT  MUGU  CA  93042 


A  p  |_£jy  f  j|^ 

GENERAL  DYNAMICS  CORPORATION 
PROJECT  COORDINATOR 
P  0  BOX  748  MZ  1884 
FORT  WORTH  TX  76101 


GARNET  M  LIEBLICH  ,  _ 

GLOBAL  FNGRG  DOCUMENTATION  SER 
3301  W  MAC  ARTHUR  BLVD 
SANTA  ANA  CA  92704 


GLOBAL  ENORpOOCUMENTATION 
ARTHUR  ■'LVO 

SANTA  ANA  CA  927U4 


SB 


ROBERT  D  LINT  _ _ntN 

HONEYWELL »  INCORPORATED 
OATA  MANAGEMENT  SPECIALIST 
5303  SHILSHQLE  AVENUE  NW 
SEATTLE  WA  98107 


UeROJETTSERVICES  COMPANY 
SUPV  DATA  MANAGEMENT 
P  0  BOX  13618,  BLDG  2001 
SACRAMENTO  CA  95«13 


n 


<4 


r>s 


CELIA  A  LANG 

LOCKHEED  MISSILES  &  SPCE  CO 
INFORMATION  RETRI EVAL  ANALYST 
P  0  POX  504  B/LOS  OR ON  50-13 
SUNNYVALE  CA  94086 


ELEANOR  LACZ 

NAVAL  SEA  SYSTEMS  COMMAND 
DEPARTMENT  JP  THE  NAVY 
CODE  PMS  400  F35 
WASHINGTON  DC  20362 


5SI85K  kEfcS  syst^s 

1100  W  HOLLYVALE  AVt 
AZUSA  CA 


91702 


GUY  A.  LOOKER 
MANAGER,  ENG  SERVICES 
p  0  BOX  13618  °LDG  2001 
SACRAMENTO  CA  95813 


*  N* 


Z-8 


1 


OONALO  M  MACALA 
INTERSTATE  ELECTRONICS  CORP 
SUPV  SUBMARINE  SYSTEMS  PRO 
P  0  BOX  3117 

ANAHEIM  CA  92603 


MR  JOSEPH  R  MEITZ 

GENERAL  MOTORS  CORPORATION 

ELECTRONICS  DRI 

GOLETA  CA  93017 


DORIS  L  MAEOA 
NAVAL  AVIONICS  CENTER 
CODE  911-4 
6000  E  2 1  ST  ST 
INOIANAPOLIS  IN  46218 


R  A  MERLU2Z0 
RAYTHEON  COMPANY 
MISSILES  SYSTEMS  DIVISION 
BOX  238 

BEDFORD  MA  01730 


GEORGE  MAEOA 

AEROJET  ELECTRO  SYSTEMS  CO 

1100  W  HOLLYVALE 

AZUSA  CA  91702 


MIKE  MICHAELI S*  USN 
UN  NAV  CONST.  BATTN  CNT 
CODE  1564 
PORT  HUENEME 

PORT  HUENEME  CA  93041 


HAROLD  J  MATURI 
MCLAUGHLIN  RESEARCH  CORP 
PROGRAM  MANAGER 
P  0  BOX  132 

MIDOLETOWN  RI  02840 


MR  L  E  MC  GAULEY 
2100  JOHN  STREET 
MANHATTAN  BCH  CA  90266 


MR  HUGH  A  MILLER 
NAVAL  ORDNANCE  STATION 
5013 

INDIAN  HEAD  MD  20640 


OONALO  R  MITCHELL 
OASO/18D-OMSSO 
CAMERON  STATION 

ALEXANOIRA  VA  22314 


EARL  L  MCCARTY 
NORTHROP  CORP 
ELECTRO-MECHANICAL  0 
500  F  ORANGE  THORPE  A 
ANAHEIM  CA 


IV 

VE 

92801 


EDWARD  V  MITCHELL*  JR 
WESTINGHOUSE  ELECTRIC  CORP 
SUPERVISOR  DESIGN  DRAFTING 
HENDY  AVENUE 

SUNNYVALE  CA  94083 


W  G  MCCLAIN 

6565  ARLINGTON  8LVD  M/C  249 
FALLS  CHURCH  VA  22046 


CYNTHIA  A  MCMILLAN 
OATA  ASSISTANT 
ASD/YXC. P  A— 10  SPO 
WRIGHT-PATT  AFB  OH  45433 


W.  A.  MORAN 

16439  FILBFRT  STREET 

FOUNTAIN  VALLEY  CA  92708 


WARREN  C  MORRIS 

USA  MISSILE  MATERIEL  READINGS' 

COMMAND 

REDSTONE  ARSNL  AL  358J9 


WILLIAM  MCNUTT 

THE  VOUCH T  CORPORATION 

CONFIGURATION  MANAGER 

P  0  30 X  225907 

DALLAS  TX  75265 


CARL  A  NELSON 

NAVAL  SURFACE  WEAPONS  CENTER 
WHITE  OAK 
COOE  WE-2L 

SILVER  SPRING  MD  20910 


Z-9 


MAJ  LANCE  NESBITT*  USAF 
HQ*  AFALD 


UNITED  STATES  AIR  FORCE 
WRIGHT-PATTERSON  AFB 
WRIGHT-PATT  OH  45433 


JOSEPH  W  PECK 
USA  TARAOCOM 
MECHANICAL  ENGINEER 
100  MERIDAN 

DEARBORN  MI  48124 


V  A  NESS 
VOUGHT  CORP 
P  0  BOX  225907 
PALLAS  TX 


75265 


MR  A  J  PENTA 

ARMY  ELECTRONICS  COMMAND 
ORSEL-RD-EB 

FORT  MONMOUTH  NJ  07703 


EDWARD  H.  NEWMAN 

USAF  SPACE  £  MISSILE  SYS  QRGN 

WORLDWAY  POSTAL  CENTER 

P  0  BOX  92960 

LOS  ANGELES  CA  90009 


ARNOLD  C  NOBLE 
INTERSTATE  ELECTRONICS  CORP 
707  E  VERMONT  AVENUE 
ANAHEIM  CA  92803 


ROBERT  E.  PERRI 
LOCKHEED  MSLE  t  SPACE  CO. 
P.O.  BOX  504 

SUNNYVALE  CA  94088 


HAL  PETERS 

MOTOROLA*  INCORPORATED 
MGR  CONFIGURATION/DATA  MOMENT 
8201  EAST  MCDOWELL  ROAD 
SCOTTSDALE  AZ  85252 


MR  JOSEPH  J  0  CALLAHAN  II 
AVONDALE  SHIPYARDS  INC 
MAIL  STATION  80 
P  0  BOX  50280 

NEW  ORLEANS  LA  70150 


NORMAN  W  O*  RORKE 

JOINT  TACTICAL  COMMUNICATIONS 

CONFIGURATION  MOMENT  OFFICER 

197  HANCE  AVENUE 

TINTON  FALLS  NJ  07724 


ELIZABETH  A  0‘SHFA 
HQ  USAF 

DATA  MANAGEMENT  SPECIALIST 

706  BRADFORD  DR  I V t 

FORT  WALTON  BCH  F|  32548 


JAMES  F  PRICE 
AEROJET  SERVICES  COMPANY 
SUPV  ENGINEER  DOCUMENTATION 
P  0  BOX  13618*  8LDC,  2001A 
SACRAMENTO  CA  95813 


JOHN  E  PROZA 
ROCKWELL  INTERNATIONAL 
CM  DEPARTMENT  MANAGER 
1200  N  ALMA  ROAD 
RICHARDSON  TX  75030 


ERNEST  C  QUILLEN 
5222  GATHER  ROAD 
SPRINGFIELD  VA  22151 


JAMES  J  REDDEN 
NAVAL  SHIP  WEA  SYS  ENG  STA 
CRUISE  MISSILE  ENG  DIV  HEAD 
PORT  HUENEME  CA  93041 


FRANK  A.  SCIORTINO 
U.S.  AIR  FORCE 

TECHNICAL  DATA  MGMENT  OFFICER 
NCA/EIEXR 

GRIFFISS  AF3  NY  13441 


MARV  REEVES 

EMERSON  ELECTRIC  COMPANY 
PRODUCT  SUPPORT  SPECIALIST 
ST  LOUIS  MO  63136 


ALLAN  D.  SIGNOR 
US  NAVAL  SHIP  WEA  SYS  ENGR. 
DATA  MGR.  FOR  THE  GFCS  MK  86 
CODE  5121  U.S.N.S.W.S.E.S. 
PORT  HUENEME  CA  93041 


MR  0  M  REIMER 

1983  RIVER  SHORES  OR 

INDI ALANTIC  FL  ' 


32901 


SHELDON  SIMMONS 
NAVAL  SHIP  WEAPONS  SYS 
ENGRG  STATION  CODE  5130 
PORT  HUENEME  CA 


93043 


MR  ROBERT  D  RHODES 
LOCKHEED  MISSILE  £  SPACE  CO 
ORGN  50-13  BLDG  102 
1824  FALLEN  LEAF  LANE 
LOS  ALTOS  CA  94022 


WALTER  J  SISLO 

FLOW  GENERAL  INCORPORATED 

SWL  DIVISION 

7926  JONES  BRANCH  DRIVE 

MCLEAN  VA  22101 


VINCENT  R  ROGGERO 
NAVAL  UNOERWATER  SYSTEMS  CTR 
CONFIGURATION  MGMENT  SPEC. 
CCSMA  TRIDENT 

NEWPORT  R I  02840 


WALLACE  E  ROOK 
CERBERONICS  INC 
5600  COLUMBIA  PIKE 
FALLS  CHURCH  VA 


22041 


HAL  E.  ROWLAND 

SUNOSTRAND  AVIATION  OPERATIONS 
CONTRACT  DATA  MANAGER 
4747  HARRISON  AVENUE 
ROCKFORD  IL  61101 


MR  BURTON  G  SCHAEFER 
DIXON  SINTALOY  INC 
535  20Pe  STREET 
STAMFORD  CT 


06906 


0  M  SCHWARTZ 

LOCKHEED  MISSILES  £  SPACE  CO 
TECH  DEV  LOR*  DEPT  56-01 
P  0  BOX  504  BLOG  572 
SUNNYVALE  CA  94096 


RICHARD  P  SMITH 
HONEYWELL  INC 

MGR  DOCUMENTATION  CONFIG  MGT 
13350  U  S  HIGHWAY  19  NORTH 
ST  PETERSBURG  FL  33733 


R.  LEON  SNODGRASS 
E  G  £  G 
ENGINEER 

2150  FIELDS  ROAD 
ROCKVILLE  MD 


20840 


ROY  SOUTHWICK 

THE  MARQUAROT  COMPANY 

ig5llGsS??g5vA??INISTRATOR 

CAN  NUYS  CA  91409 


PHI  LOME  NF  C.  SPISAK 

DATA  MANAGEMENT  SPECIALIST 

SAMSO  MN8D 

NORTON  AIR  FOCE  BASE 

NORTON  AFB  CA  92409 


NORMAN  STEIN 
GTE  SYLVANIA 
P.O.  BOX  188 
MOUNTAIN  VIEW  CA 


94042 


V. 


z-n 


CHARLES  L  STEWART- 
US  ARMY  MIRAOCOM-TGG 
HUNTSVILLE  AL  35804 


RON  TAIN 

EMERSON  ELECTRIC  COMPANY 
SUPERVISOR  CONFIGURATION  MGMT 
8100  W  FLORRISANT 
ST,  LOUIS  MO  63136 


ROGER  A  STORMS 

SPERRY  UNIVAC  CONFIG  MGMT 

UNIVAC  PARK 

P  0  BOX  3525  MS  U1E16 

ST  PAUL  MN  55165 


A.  G,  THALHAMER 
NAVAL  E.O.D.  FACILITY 
INDIAN  HEAD  MD 


20601 


MR  ALBERT  R  STROW 
RAYTHEON  COMPANY 
HARTWELL  ROAD 

BEDFORD  MA  01730 


CHARLES  E,  TIEDEMANN 
MCOONNELL  DOUGLAS  ASTRONAUTIC 
ROOM  292 
PO  BOX  516 

ST.  LOUIS  MO  63166 


ROY  F  SUGIMOT 0 

F— 1 6  DATA  MGT.DIV. SYS. AERO  SY 
ASD/YPCD 

W-PATTERSON  OH  45433 


ROBERT  L  TISCHER 
HO  UNITED  STATES  AIR  FORCE 
INTERMEDIATE  DATA  MGMENT  OFF 
CODE  ASD/AWZ 

WRIGHT-PATT  AFB  OH  45433 


ALLEN  SUMIDA 
LOCKHEED 

NAVAL  REPRESENTATIVE  OFFICE 
P  0  BOX  504 

SUNNYVALE  CA  94086 


WILLIAM  J  TOEPPE 
INTERSTATE  ELECTRONICS  CORP 
700  EAST  TAFT  AVENUE*  UNIT  19 
ORANGE  CA  92665 


MR  J  R  SUTTON 

GENERAL  ELECTRIC  COMPANY 

ORDNANCE  DIVISION 

100  PLASTICS  AVE  RM  842 

PITTSFIELD  MA  0I20I 


DONALD  K  SWANSON 
DEFENSE  ELECTRONICS  SUPPLY  CTR 
CHIEF  PARTS  CONTROL  DIVISION 
1507  WILMINGTON  AVENUE 
DAYTON  OH  45444 


J  W  TOKARCIK 
HARRY  DIAMOND  LABS 
CH  CONFIGURATION  MGMT  BR 
2800  POWDER  MILL  RD 
ADELPHI  MD  20783 


GEORGE  V  TRIVOLI 

CUBIC  CORPORATION 

PROGRAM  MANAGER 

9233  BALBOA  AVENUE 

SAN  DIEGO  CA  92138 


JOSEPH  V.  SYMANOSKIE 
E-SYSTFMS*  INC. 

MELPAR  DIVISION 
7700  ARLINGTON  3LV0. 

FALLS  CHURCH  VA  22046 


pimUKilc  C  iAYLOR 
U  S  ARMY  ARMAMENT  RESEARCH 
AND  DEVELOPMENT  COMMAND 
ATTN  DRDAR-TST-S 
DOVER  NJ 


ROBERT  B  TWITCHELL 
MOTOROLA  INC  GED 
CONFIGURATION  DATA  MANAGER 
8201  E  MCDOWELL  RD  AREA  2151 
SCOTTSDALE  A?  85252 


ELEANOR  A  TWOMEY 

H3  USA  ERA DCOM 

ELECTRONIC  ENGINEER 

CODE  DELET-DT 

FORT  MONMOUTH  NJ  07703 


07801 


RQNALO  L  VAN  BUSK  IRK 
GENERAL  DYNAMICS 
1675  W  MISSION  BLVO 
P  0  POX  2507 
POMONA  CA 


RENE  VAN  DE  VELOE 
CUPIC  CORPORATION 
CONFIGURATION  MANAGER 
9233  BALBOA  AVENUE 


91766 


DIEGO  CA 


92138 


JOSEPH  A  VERAS 

MCDONNELL  DOUGLAS  ELECTRONIC 
P  0  BOX  426 

ST  CHARLES  MO  63301 


BENTON  A  VIZ2ER,  SR 

PRC  TECHNICAL  APPLICATIONS 

PROJECT  MANAGER 

7618  S  MEMORIAL  PARKWAY 

HUNTSVILLE  AL  35802 


CHARLES  R  VOSS 
PRODUCT  ASSURANCE  MANAGER 
632  PENNSYLVANIA  AVENUE 
HARTSHORNE  OK  74*^47 


JAMES  VOVOU 

GOVERNMENT  PRODUCTS  DIVISION 
CONTRACT  £  SPEC  ANALYST 
P.O.  BOX  2691 

WEST  PALM  BEACH  FL  33402 


GAPY  J  WALDEN 

AERONUTRONIC-FORD 

WDL  DIVISION 

3939  FABIAN  WAY 

PALO  ALTO  CA  94303 


MICHAEL  W  WALKER 

CENTURY  GRAPHICS 

ASK  10  PRODUCTION  SUPERVISOR 

19773  BAHAMA 

NORTHR IDGE  CA  91324 


DR  PETER  C  C  WANG 
DEPT  OF  MATH  AND  NATIONAL 
SECURITY  AFFAIRS 
NAVAL  POSTGRADUATE  SCHOOL 
MONTEREY  CA  93940 


Z-13 


J  H  WARNER 

FORD  AEROSPACE  L  COMM  CORP 

SUPERVISOR 

FORD  ROAO 

NEWPORT  BEACH  CA  92663 


CARL  E.  WEBB 

STRATEGIC  SYSTEMS  PROJECT  OFF. 
SVPER  AEROSPACE  ENGINEER 
P.O.  BOX  504. NAVAL  PLANT  REP. 
SUNNYVALE  CA  94086 


ALAN  E  WEISS 

LOCKHEOD  MISSILES  t  SPACE  CO 
PROGRAM  PLANNING  SPECIALIST 
P  0  BOX  504 

SUNNYVALE  CA  94086 


WAYNE  H  WHEELER 
MOTOROLA  INC  G  E  0 
8201  EAST  MCDOWELL  ROAD 
P  0  BOX  1417  MAIL  DROP  2112 
SCOTTSOALE  AZ  85252 


JAMES  A  WHITLOCK 
GENERAL  ELECTRIC  CO 
HQ/E  SD/DCM 
HANSCOM  AFB 

BEDFORD  MA  01731 


J  R  W I FHL 

GRUMMAN  AEROSPACE  CORPORATION 
MS  540-PL35 

RETHPAGE  NY  11714 


R  L  WILLIAMS 

KAMAN  SCIENCES  CORPORATION 
P  0  BOX  7463 

COLORADO  SPRING  CO  89933 


JACK  L  WILSON 
SUPERVISOR  8413-1 
SANDIA  LABORATORIES 
P  0  BOX  969 
LIVERMORE  CA 


g 


94550 


JANET  L  WILSON 
LITTON-GUIDANCE  CONTROL 
PROJECT  ANALYST 
5500  CANOGA  AVENUE  MS  74-31 
WOODLAND  HILLS  CA  91364 


let* 


